Klartext please !

Hey all,

I won't comment too much here right now (I am kinda busy with work), but imaginably in relation to my last blog post:

http://www.microsoft.com/technet/security/bulletin/ms09-jul-ans.mspx

Now my favourite quote from http://blogs.technet.com/msrc/ :

"While we can’t go into specifics about the issue prior to release, we can say that the Visual Studio bulletin will address an issue that can affect certain types of applications."

I would be tempted to say that "if you can't say anything useful, say nothing at all", but I am often guilty of writing useless things, so I won't.

The above formulation inspired me though:

• "While I have no clue what this out-of-band patch is all about, it will address an issue that has to do with a programming mistake."
• "While going into the specifics would be dangerous to the safety of the world, the issue that will be addressed is an issue that can affect computers."
  

Sigh. Newspeak.

There is a German expression called "Klartext reden" (literally translated 'to speak clear text'). If you know a german, grab him, and ask him to explain the meaning of the word to you. I wish there was more of this around.

So my 2 cents of speculation:

• MS will patch a bunch of libraries (the ATL ?) in Visual Studio
  
• A "certain type" of application is affected and will need recompiling. The msvidctl thingie was an ActiveX component. Anybody wants to add 2 and 2 together ?

I really need to get back to work though.

Poking around MSVIDCTL.DLL

Hey all,

I have to admit that I did not follow the msvidctl.dll situation all that closely, except for my short tweet that this bug was apparently reported more than a year ago. Yesterday, my old friend Dennis Elser piqued my interest: He had isolated the bug down to a function called ATL::CComVariant::ReadFromStream. He had determined that the function in question made a rather strange mistake: Instead of passing a pointer to a data buffer to IStream::Read, it took the address of a (small) local variable, and passes this address as output buffer to IStream::Read, along with a length read from the stream previously.

Somebody clearly got confused.

So Dennis and me sat down tonight and did a bit of digging around and tried to clarify what was going on. So we dug in a bit deeper, and ended up with the following understanding of the situation:

1. If the stuff that is supposed to be deserialized does not contain the proper value in the first 2 bytes, 8 more bytes are read, and SafeArrayCreate is used to create a new array with a 4-byte size obtained from these bytes.
2. A pointer to the allocated memory is obtained by ways of calling SafeArrayAccessData. This function places a pointer to the memory in question into a memory cell pointed to by it's second argument.
   
3. Instead of passing the CONTENTS of the memory cell pointed to by the second argument to IStream::Read, the code in question passes the address of this variable in. This happens to be the re-used memory for the first argument of ReadFromStream, hence it is on the stack. Memory corruption hilarity ensues.

This is a cute little bug. First of all, it is a beautiful example of a single excess "&" in the source code. But what is most amusing about this bug is the centrality of it -- it is, after all, in a method of a class from the ATL.

Everybody loves bugs in libraries. Few things fill my heart with quite as much amusement as bugs in heavily-used, statically-linked libraries. OpenSSL (and libeay) was good for many laughs in the past, zlib was a favourite for a long time, too.

So what we have here is a bug in a component that is used fairly widely, and that has the property of being statically linked (yay templates !).

Now, a quick search of my harddisk turned out that a lot of third-party components (flash) contain the same function -- but in old and non-vulnerable versions (for an extra dash of irony, the function used to be safe before all this SafeArray-stuff was added). Only a small fraction of the files that use the ATL and contain this function appear to contain it in a vulnerable version.

We ended up building a really naive / stupid / false-negative-and-false-positive-prone regexp to scan for the vulnerable basic block. This is of course going to fail if anyone has tweaked their optimization settings etc., but it would still be interesting to find out how many files contain this "trivial" byte string.

So I searched my windows directory for the following regexp pattern:

pattern = "\x8B\x07\x6A\x00\xFF\x75\x2E\x8D\x4D\x2E\x51\x57\xFF\x50\x0C\x53"
r = re.compile( pattern, re.DOTALL )

There were a few files in which this pattern was found (XP):

Found pattern in file c:\Windows\system32\ieframe.dll
Found pattern in file c:\Windows\system32\mstscax.dll
Found pattern in file c:\Windows\system32\msvidctl.dll
Found pattern in file c:\Windows\system32\wmp.dll
Found pattern in file c:\Windows\system32\wmpdxm.dll

Dennis searched for the same pattern on his disk (Vista) and found:

c:\windows\system32\cic.dll
c:\windows\system32\comsnap.dll
c:\windows\system32\comsvcs.dll
c:\windows\system32\ieframe.dll
c:\windows\system32\mmcndmgr.dll
c:\windows\system32\mstscax.dll
c:\windows\system32\MSVidCtl.dll
c:\windows\system32\puiobj.dll
c:\windows\system32\rdpencom.dll
c:\windows\system32\shdocvw.dll
c:\windows\system32\wiaaut.dll
c:\windows\system32\wmp.dll
c:\windows\system32\wmpdxm.dll

Why the difference ? Well, amusingly, shdocvw.dll on my XP machine doesn't have this SafeArray-stuff in it yet -- it is probably compiled using an older, not vulnerable variant of the ATL -- wheras Dennis variant of the same DLL is much newer, compiled with the 'broken' variant of the ATL.

So, where does this leave us ?

1. The bug is actually much "deeper" than most people realize.
2. The killbit-fix is clearly insufficient, as there are bound to be many other ways of triggering the issue.
   
3. The bug might have weaseled it's way into third-party components, IF anyone outside of Microsoft had access to the broken ATL versions.
   
4. If this has happened, MS might have accidentally introduced security vulnerabilities into third-party products.
5. Depending on the optimization settings applied to the executables, it might require a bit of an effort to find out whether a vulnerable or non-vulnerable version of the code is present.
6. There might be a lot of recompiling next week.
7. IF this has gotten into third-party-products, I would bet that only a tiny fraction of software vendors will push out proper/timely updates.

It just seems that spending time to improve BinDiffs ability to find statically linked libraries might have been worth it :-)

Anyhow, I really need to get to sleep -- I have a train to catch in a bit more than 4 hours.

A lot of credit for this post has to go to Dennis Elser -- he did most of the hard work before we sat down.

Las Vegas / Blackhat / DefCon

Hey all,

the annual Blackhat / DefCon thing is coming up again, and I just wanted to announce here that I will be in Las Vegas from the 24th of July to the 2nd of August. I will be busy teaching classes until the 28th of July, but thereafter I am mostly free (e.g. roaming the conference). If you wish to schedule a demo for any of our products (BinDiff, BinNavi, VxClass) or just generally have a chat about all things related to reverse engineering, vulnerability analysis, malware classification, deobfuscation, math or business, do not hesitate to contact me beforehand :-)

Cheers,
Halvar

Strange Cellphone Behavior

Hey all,

I know this blog post is a bit weird, but I reckon I'd share this: For some reason that is quite unknown to me, my cellphones have a habit of developing strange behaviors. I used to use a Nokia N73, which developed the following habit:

When in foreign time zones (Japan, Norway, USA) the phone would send more-or-less random old text messages to more-or-less random people from my address book. There would be a merry mix & match between the two, leading to more than one amusing misunderstanding that needed clearing up.

Then, at some point last fall, I switched to the silly shiny Apple telephony device (perhaps people do better QA on their backdoors on that platform). For a few months, the problems went away.
This changed last week -- now, when I send text messages to certain numbers, the phone seems to send a more-or-less random old text messages that has already been sent to the same number along with the message. This is a bit nicer (as it will not mix & match), but still annoying.

So .. uhm ... I am trying to come up with plausible explanations for this behavior. Can anyone offer one ? My total-guess-in-the-dark ideas would be:

1. Current behavior is caused by international text message routing weirdness -- e.g. text messages I sent a few days ago in the US get duplicated for some reason and re-sent
2. Both current and N73 behavior is triggered by shoddy QA on lawful intercept systems
3. Both current and N73 behavior is triggered by shoddy QA on the side of the parties that backdoor my phones

Now, I don't know if anyone else has ever suffered from this, or if there is a perfectly valid and proper explanation, or if there is an easy way to do diagnostics, but:

1. If you backdoor my phone, fix your software. Kthx.
   
2. If you write LI software, fix your software. Kthx.
   
3. If there are multiple people backdooring my phone, please test for interoperability between your tools.
   

So, any other theories on what might be going on ?

Reverse Engineering / Bug hunting trainings in Amsterdam

Hey all,

I haven't given a reverse engineering trainings class in Amsterdam for a few years, but this year is different :-) -- I will be at BH Amsterdam, and there are still seats open in the trainings class for April 14th and 15th.

What will be done in the course ? Well, for one thing, we'll go bug-hunting in some interesting piece of code. Furthermore, we'll talk quite a bit about C++ and it's effects in the binary. We'll do a fair bit of differential debugging, some more bug-hunting, and a lot of IDA automation. Questions like

• given a C++ executable, how do I recover an inheritance diagram of the classes ?
• given a big and ugly executable, how do I find the interesting places to focus on ?
• how do I make sure IDAPython and NaviPython make my life easier ?

will be treated thoroughly.

So, if you still have some trainings/travel budget left in spite of the crisis, you can find more
details here.

Diffing x86 vs ARM code

I posted a while ago about the new DiffDeluxe comparison engine, and that we'd release it in Q1 2009. Well, we're almost there, the engine is now in beta. If you are a BinDiff user and wish to give the new engine a try, send mail to info@zynamics.com :-)

I mentioned in my last post on the topic that DiffDeluxe was designed to facilitate symbol porting, and to allow comparisons between executables that are "far away" from each other.

In the last post I wrote about Mozilla JS engine vs. Acrobat EScript.dll. Today I am going to try something slightly crazier: In order to evaluate how well these matching algorithms work, we will be diffing an executable that was compiled for ARM against a very similar executable compiled for x86.

My coworker Vincenzo is a big fan of all things OSX, and he brought up the idea of comparing x86 and ARM versions of the OSX dynamic loader -- namely the disassembly of dyld on the iphone against the disassembly of dyld on OSX.

Now, the first voices are going to yell: "You have names for all functions, BinDiffing is easy then!". Well, true, but we will run DiffDeluxe without taking the names into account, and then just using the names to validate the results.

The two executables have 704 (x86) and 618 (ARM) functions respectively. Without name
matching, we match 345 functions. Inspecting the symbols, we see that we have matched
160 of these functions in full accordance with the symbols. Let's have a look at some of the details:

Cute, eh ? Let's look at some more...

It is almost surprising how far one can get without actually looking at the instruction semantics.

If we take the names into account, matching functions becomes easy, but matching basic blocks properly ends up the difficulty. With name matching enabled, DiffDeluxe matches 3809 basic blocks, out of 7904 respective 5196.

So to summarize: The structural comparison is sufficiently strong to yield some useful results even accross two different CPUs. While there is still (a good amount) of room for improvement, I am quite happy with these results so far :-)

So, if you want to beta, and you already use BinDiff, drop us a line !

Washington DC, Trainings, Demos :-)

Hey all,

I will be in Washington DC from the 16th to the 20th of February. Amongst other things, I will be teaching a course at Blackhat DC. The economic crisis is clearly hitting -- e.g. there are still seats available. We will also get around to using some of the nice features of BinNavi v2 in class, which I am looking forwards to.

Now, aside from the course: If you are in the DC area and interested in a product demo for BinDiff (and the upcoming DiffDeluxe), BinNavi v2 (including REIL), or the latest VxClass (now available as service and virtual appliance), do not hesitate to drop a line to info@zynamics.com :-)

Correction: Clam *does* have some unpacking support

Correction of my last post: It appears that Clam has *some* unpacking support. It is not as comprehensive as some of us would like, but progress is being made :-)

ClamAV and unpackers

Hey all,

this might be a rather odd question, but given the (unfortunate) fact that ClamAV can't unpack
even the simplest packers, has nobody ever contemplated writing packer-specific unpackers
for ClamAV ?

Cheers,
Halvar

TAOSSA blog post I didn't see but will comment on :-)

http://taossa.com/index.php/2008/10/13/bugs-vs-flaws/#more-83

I didn't see this post beforehand, and I would like to comment on it (mainly because commenting on his blog post might be the easiest way of getting into a conversation with Mr. McDonald these days ;), but I don't have time right now. Will fix this later this week hopefully.

Sometimes, diffing can remove obfuscation (albeit rarely)

Hey all,

apologies for the sensationalist title, but I found another amusing example today where the same function was present in two different executables -- in two differently obfuscated forms. Amusingly, DiffDeluxe identified the "common components" between these two functions, effectively removing a lot of the obfuscation.


While this is clearly not a typical case, it nonetheless made me smile.

Merry Christmas everyone !

A good protocol attack ...

... is like a good joke. This one, while requiring special circumstances to succeed with high probability, was responsible for a lot of laughter on my side.

BinDiff / BinNavi User Forum

Hey all,

we have re-activated the BinDiff / BinNavi User Forum under

https://zynamics.fogbugz.com/default.asp?BinNavi
https://zynamics.fogbugz.com/default.asp?BinDiff

There is not a whole lot there at the moment, but that should change soon :)

Malicious Office/PDFs

Hey all,

for some research that I'm doing, I'm looking for a collection of malicious Office/PDF documents. If anyone has such documents (e.g. because he was targeted in an attack, or because he found one somewhere), I'd much appreciate submissions ! :)

BinNavi v2 and PHP !

Hey all,

we have written about the SQL storage format for BinNavi quite a few times on this blog, and how we'd like to encourage third parties to use it. I am quite happy to say that Stefan Esser of
SektionEins GmbH has built code to export PHP byte code into the database format. The (cute) results can be seen under

http://www.suspekt.org/2008/11/05/php-bytecode-in-binnavi-20/

German ways of expressing optimism

One of my favourite things when travelling and interacting people from other cultures is observing differences in conversational conventions -- and (most importantly) different forms and perceptions of "conversational humor". Aside from comedic protocol screw-ups (e.g. literally translating an essentially untranslateable expression to another language, earning -- at best -- puzzled looks and -- at worst -- thoroughly offending the conversation partner), it often provides interesting insights into one's own culture and habits.

This weeks special: German forms of expressing optimism.

There are many expressions in German that are horribly difficult to translate.

One of my favourites that could cause confusion is the German custom of wishing people luck by wishing them "Hals- und Beinbruch!" (literally: 'broken neck and broken leg') or 'Kopf- und Bauchschuss' (literally: 'shot in the head and stomach') or (for sailors) 'Mast- und Schotbruch' (literally: 'broken mast and ripped sail') upon parting.
A common reply for this would be "wird schon schiefgehen" (literally: 'I have no doubt it's going to go badly'). Counterintuitively, the semantics of this is optimistic -- e.g. whoever says that things are going to turn out badly indicates by this that he is not worried, and that he actually expects that things will be fine.

In essence, one expresses optimism by claiming that an improbably horrible outcome is a near-certainty.

Even though I try hard to not have an all-too-obvious German accent any more, I do catch myself all the time in using the above pattern, even though it does not translate. I (deservedly) earned puzzled looks today by clumsily attempting to use the following German saying to indicate my optimism about the future:

"Lächle und sei froh, sagten sie mir, denn es könnte schlimmer kommen. Und ich lächelte und war froh, und es kam schlimmer."

This has a certain elegance in German, which is totally lost in my clumsy translation:

"Smile and be happy, they told me, because things could be a lot worse. So I smiled and was happy, and things got a lot worse."

Aside from the clumsiness of the expression when translated, the semantics (e.g. the intention to express optimism) was thoroughly lost -- the effect was a thoroughly puzzled and slightly worried look by my conversation partner. I think it is situations like these where Germans earn their bad reputation for being thoroughly unfunny.

Other things that are good for causing confusion between a native English speaker who interacts with someone from the German-speaking world are differences when it comes to acceptable replies to the question "How are you ?". The usual form of this in German is "Wie gehts ?", essentially "How is it going ?". In the English speaking world, acceptable replies seem to be restricted to "good", "good good", or "great".

Proper replies to the question "How is it going" over here would be:
"Muss." -- literal translation: 'it has to somehow'
"Naja, ganz ok." -- 'well... ok ...'
"Könnte schlechter/besser gehen" -- 'could be worse/better'
"Bergauf" or "Bergab" -- uphill / downhill

If the other party feels inclined to have a longer chat, they could reply with
"Yesterday, we stood on a cliff. Today we have advanced by a significant step."
or "Katastrophe". This is usually followed with a short anecdote or complaint about something work-related. From a social perspective, this does wonders as an ice-breaker.

Whenever I catch myself in such a situation, I realize that no matter how much one travels, and no matter how much time one spends in a different cultural climate, certain components of the social interaction are nigh-impossible to change.

Anyhow, time to go to sleep.

The joys of the Volkswagen Caddy Natural Gas car

So I do own a car (contrary to what most people expect). About a year ago, I bought a VW Caddy EcoFuel. It runs on natural gas in normal mode and only uses the gasoline tank for starting (and when the natural gas has run out).

Up until 4 weeks or so ago I was pretty happy with it, but one morning, the car refused to start unless I hit the gas heavily while starting. I brought the car to the repair shop that belongs to the same place where I bought the car. After a few days of tinkering, they told me that

1. The particular car I own doesn't lock the tank when the rest of the car is locked and
2. Somebody poured an unidentifiable liquid into my tank causing the problems
3. Because this is not a problem with the car itself, warranty doesn't cover it
4. Removing the tank and the fuel pump and cleaning everything is going to cost 1200 EU

I am somewhat annoyed by some punk pouring an unidentifiable liquid into my tank and agree to pay the money. I also ask for the shop to retain a sample of the tank contents so I can at least find out what was poured into the tank, and perhaps get money back from my insurance.

They agree. When I come to pick up the car, the guys at the shop for some bizarre reason cannot find the sample. I sit and wait for ~1 hour, and they finally produce an unlabelled can from somewhere. Ok. I ask them to sign a piece of paper certifying that this sample is coming from my tank, and they tell me they will send it to me via regular mail the next day. So far so good.

So two weeks pass, and I call back 3 times for that piece of paper. At the beginning of the third week, I have to take my guinea pigs to the vet in the morning (yes, I don't only own a car, I also have guinea pigs). On my way back from the vet, the natural gas runs out, and the car switches to gasoline mode -- while I am going about 130km/h with a large truck behind me. The only complication: My engine switches off. Awesome.

So I manage to stop the car safely on the side of the autobahn and get towed to the next Volkswagen shop. About 2 hours after I leave my car there, I get a call from the repair guy there, telling me that they can see in the VW database which repairs were done on my car recently, but from what they can tell, these repairs never happened. They call in an expert that is certified to appear in court to take pictures & write a report, and he also confirms: The tank was never removed, the gasoline pump never replaced, and the 1200 EU were apparently charged without any of the stuff ever happening.

Clearly, I am somewhat surprised. To my dismay, I am also told that the actual repairs will cost about 2000 EU, and that there is still unidentified stuff in my tank.

So all in all, I am currently stuck with

1. 1200 EU for repairs that never happened
2. 2000 EU for repairs that are happening now
3. 2 * 300 EU for chemical analysis of the two samples taken
4. unspecified legal costs (most likely covered by my insurance) to deal with the situation

All in all, I am quite dissatisfied with VW on this front -- IMO they should've warned me that the tank doesn't lock, and they shouldn't have "VW Certified Repair Shops" that appear to attempt to defraud customers. I have trouble imagining that not actually performing the repairs was an "honest mistake" (although I usually live by the motto that "one should not attribute anything to malice that can be attributed to incompetence").

Anyhow, let's see how this plays out. As if I don't have other stuff to do.

For those playing with the printer bug...

... I can't help but post this small PNG. And since blogger rescales/blurs the picture, here is a link to the "full" one.

My bro's comments on the financial crisis

My brother wrote an article injecting some reality into the discussion about the banking crisis on Spiegel Online. The german version can be seen here. I'll share a short summary of his arguments here (and he'll complain about my distortions later ;).

Short version: The article describes why the situation is less dire than many pundits claim, and explains logical fallacies in commonly-heard arguments.

In the following, here's a summary of his arguments, in the form of "Myth --> Reality"

1. The US government is taking on a total of 7000bn in liabilities -- about 5500bn by agreeing to step in for Fannie Mae / Freddie Mac, and about 700bn in papers bought by doing the bailout. This equates to roughly half of US GDP, and since the US is already in debt by about 65% of GDP, this would push the total indebtedness of the US to be clearly past 100% of GDP. As a result, serious doubts would have to be cast on the US governments ability to repay debts and service interest on debt.
   Reality: Most of the 5500bn are backed by "proper" mortgages with decent quality. It is unclear whether the US gov will lose money on the Fannie Mae / Freddie Mac deal at all. Even the 700bn in "toxic assets" the US is willing to buy have some underlying value. Realistic expectations at the total loss for the US government in this deal runs in the area of 500bn, which would be less than 3% of GDP -- and therefore not a significant source of problems.
2. The liquidity that central banks are injecting into the markets should lead to hyperinflation. Reality: The measures to help liquidity in the markets do not increase the money supply in the long run. They are usually short-term credits given to struggling banks for a limited amount of time -- weeks or months. After this time, the creditors have to repay the loans, and the money disappears. At the same time, the willingness by existing banks to lend decreases, thus decreasing the money supply in the economy. The statistics by central banks show that the actual money supply M2 is growing a lot less slowly at the moment in spite of all the liquidity injections. Since the money supply is only growing very slowly at the moment, the inflationary pressures are low.
   
3. The banking crisis is responsible for the overall slowdown in the EU's economy, and the German government is thus not responsible for having to adjust their growth estimates downwards sharply.
   Reality: Most indicators show that the slowdown started way before the crisis reached it's current urgence. The indicators started pointing down much earlier as a result of the heavy increase in energy costs, the appreciation of the euro (and the resulting loss in competitiveness), and Germany's botched reform of accounting rules for writing down investments in equipment. The banking crisis is just the latest "kick" -- but the three previous ones were all known early (and could've been partially corrected).
4. This is the mother of all financial crises. This banking crisis is the worst crisis in several generations, up to the 1930's crash. Reality: Dramatic banking crises are more common than we think. Since 1970, the IWF has counted 42 crashes in countries like Argentina, Indonesia, China, Japan, Finland or Norway. In comparison to these crises, the current crisis isn't even very deep or expensive: The Paulson-bailout comes at a cost of 700bn, not even 5% of GDP, and only a fraction of this will be actually lost. According to the IWF, the average banking crisis in a country came at the cost of 13% of GDP for that country's tax payer. The Indonesian crisis even came in at four times this. The big difference to the other crises is that this one has caught on in the world's biggest economy, and as such reaches unknown dimensions in absolute terms.
   

A few things I forgot to mention :-)

Hey all,

I forgot to mention a few things in the previous post:

1. We're going to release BinDiff v2.1 on the 15th of October 2008. This is still the "old" diffing engine, albeit with a number of speed & reliability improvements.
2. We're going to release BinNavi v2.0 on the 15th of October 2008. The number of new features in this release is huge -- it's really quite significant. You can read about it in detail on SP's blog.
   I will post some more information myself in the next days. Just a few mouth-watering keywords: Plugin API to extend Navi from Java/JRuby/Jython/JavaScript, built-in intermediate language, hierarchical tagging / namespaces for structuring large disassemblies, cross-module-graphing, managing multiple address spaces in one project, many user interface improvements, faster IDA->SQL export etc. etc. etc.
3. The DiffDeluxe engine will be part of the next BinDiff release thereafter, probably no later than February 2008. If you are an existing BinDiff customer and would like to try the DiffDeluxe engine in order to provide us with feedback, do not hesitate to contact us -- it's available for testing now. We're especially interested in finding instances where DiffDeluxe performs worse than BinDiff v2.1. Switching the core diffing engine is a significant change, and I would not want to know of any instances where the new engine is worse than the old one.