New RTSP Quicktime flaw affects both OSX and Windows

Apple’s unsafe and cavalier attitude towards security puts not only Macintosh users at risk, but also Windows users. The latest QuickTime flaw demonstrates this. QuickTime is Apple’s multimedia player. It’s the part of iTunes that plays the music/videos, although you can install it separately without iTunes. Windows users who have iPods or attempt to play “.mov” videos will likely have QuickTime installed.

QuickTime is written in an inherently insecure manner. This puts at risk anybody who uses it, Windows or Macintosh. There have been a constant stream of bugs in QuickTime published over the last couple years, such as the famous 0day that won a Hack the Mac contest.

Address Space Layout Randomization

The most interesting bit of these latest QuickTime vulnerabilities is how they react with “Address Space Layout Randomization” or “ASLR”. ASLR is a technique of mixing things up in memory so that hackers cannot find them. This is armor that prevents vulnerabilities from being exploited in practice.

Apple announced ASLR as a feature in their latest version of the operating system, Mac OS X 10.5 (TigerLeopard). However, Apple largely lied. While some insignificant items were indeed randomized, nothing that hackers are interested in where changed. If Apple had fully randomized things like Windows Vista, then this QuickTime vulnerability would (likely) not be exploitable.

Does this mean that this vulnerability is not exploitable on Vista version of QuickTime? Humorously, Apple still has a problem here. Vista ASLR requires a little cooperation from developers. Developers have to link their code with the flag /dynamicbase. This sets a bit in their compiled code that tells Vista it can randomize the layout of memory. Apple developers do not set that all-important flag, telling Vista NOT to randomize their layout.

Even though Apple didn’t set it, you can set that flag yourself. It’s just a single bit within the DLL file. If you flip that bit, then Vista will load QuickTime in a randomized fashion. As far as we can tell, QuickTime runs just fine under Vista with the ASLR bit set.

The original location of QTOControl.dll.

What it look like in PE Explorer.

After its been modified save and copy it back. (note that Vista requires admin privs to copy the file)

The new location of QTOControl.dll.

Watching a video.

QuickTime has multiple executables, all of which must be changed in this manner. We set this bit on all the DLLs, then tried the latest QuickTime exploits. As we expected, setting the flag stops the exploits from working, protecting the system.

Changing a major application like QuickTime is not as easy as snapping your fingers, but Vista has been out almost a year now so it seems like support should have trickled down now. Apple should have enabled randomization in QuickTime.

RTSP handler

The easiest way to exploit QuickTime was URLs that caused it to be executed directly. Both IE7 and Firefox 2.0.0.9 have removed the rtsp:// handler. This makes it harder to reach QuickTime. Users must manually download a QuickTime file and play it, rather than simply following a link. When trying to play QuickTime files, Vista will warn the user that they may be accessing malicious content.

Below is what message I get while trying diffrent attack methods via Firefox.

Unfortunately, Safari still supports the rtsp:// handler, meaning they are at much greater risk than IE/Firefox users.

The Proof of Concept (PoC) Exploit

Below is a screen shot of gdb attach to the QuickTime Player after the exploit was successful. It is crashing because of an attempt to dereference EAX, which is 0x41414141. You can see in the instruction before EIP that EAX is loaded from a deference of EBP+0x10. Looking at EBP the pad the author of the PoC chose, 0x41, can clearly been seen.

Tracking down this bug is easy considering the information given by the PoC author about it being a stack overflow. The problem is a lack of length checking in the _EngineNotificationProc before calling a function called BlockMoveData. BlackMoveData is just a wrapper for bcopy(), a notorious bad function from a security standpoint.

Microsoft has impressed the security community with its dedication to secure coding practice. It bans dangerous functions like bcopy(), and forces its programmers to use safer versions (such as memcpy_s(),the safer version of bcopy()). Apple has not adopted secure coding practices; they still use known dangerous code such as bcopy(), sprintf(), strcpy(), and so on.

Breaking on the _EngineNotificationProc.

(gdb) set disassembly-flavor intel
(gdb) break _EngineNotificationProc
No symbol table is loaded. Use the "file" command.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (_EngineNotificationProc) pending.
(gdb) attach 316
Attaching to process 316.
Reading symbols for shared libraries . done
Reading symbols for shared libraries ..................................................................................................................... done
Breakpoint 1 at 0x174816fd
Pending breakpoint 1 - "_EngineNotificationProc" resolved
0x93442446 in GIF_CDBandDecompress ()
(gdb) c
Continuing.

Tracing the bad data.

0x174329bc in INet_GetFieldBody ()
1: x/i $eip 0x174329bc : mov edx,eax
(gdb) x/20x $ebp
0xbfffc908: 0xbfffcbc8 0x174820d8 0x17bdb811 0x00001447
0xbfffc918: 0x175732d5 0x15af8808 0x00000000 0x69746c32
0xbfffc928: 0x0000bd7e 0x00000000 0x00000012 0x00000010
0xbfffc938: 0xbfffc948 0x92d90000 0x00000012 0x00000006
0xbfffc948: 0xbfffc958 0x00200020 0x00000000 0x0083f69c
(gdb) info registers
eax 0x17bdb837 398309431
ecx 0x0 0
edx 0x15 21
ebx 0x17481708 390600456
esp 0xbfffc8e0 0xbfffc8e0
ebp 0xbfffc908 0xbfffc908
esi 0x17bdb811 398309393
edi 0x15af8808 363825160
eip 0x174329bc 0x174329bc
eflags 0x286 646
cs 0x17 23
ss 0x1f 31
ds 0x1f 31
es 0x1f 31
fs 0x0 0
gs 0x37 55
(gdb) x/20x $eax
0x17bdb837: 0x70737472 0x302f2f3a 0x302e302e 0x312f302e
0x17bdb847: 0x33706d2e 0x430a0d2f 0x65746e6f 0x542d746e
0x17bdb857: 0x3a657079 0x41414120 0x41414141 0x41414141
0x17bdb867: 0x41414141 0x41414141 0x41414141 0x41414141
0x17bdb877: 0x41414141 0x41414141 0x41414141 0x41414141
(gdb) x/20s $eax
0x17bdb837: "rtsp://0.0.0.0/1.mp3/\r\nContent-Type: ", 'A' ...
0x17bdb8ff: 'A' ...
0x17bdb9c7: 'A' ...
0x17bdba8f: 'A' ...
0x17bdbb57: 'A' ...
0x17bdbc1f: 'A' , 'B' ...
0x17bdbce7: 'B' ...
0x17bdbdaf: 'B' ...
0x17bdbe77: 'B' ...
0x17bdbf3f: 'B' ...
0x17bdc007: 'B' ...
0x17bdc0cf: 'B' ...
0x17bdc197: 'B' ...
0x17bdc25f: 'B' ...
0x17bdc327: 'B' ...
0x17bdc3ef: 'B' ...
0x17bdc4b7: 'B' ...
0x17bdc57f: 'B' ...
0x17bdc647: 'B' ...
0x17bdc70f: 'B' ...
(gdb)

The guilty system call.

1: x/i $eip 0x1748216f <_enginenotificationproc+2680>: mov DWORD PTR [esp+0x4],edx
(gdb)
0x17482173 in _EngineNotificationProc ()
1: x/i $eip 0x17482173 <_enginenotificationproc+2684>: mov DWORD PTR [esp],eax
(gdb)
0x17482176 in _EngineNotificationProc ()
1: x/i $eip 0x17482176 <_enginenotificationproc+2687>: call 0x175812ae
(gdb) x/20x $eax
0x17bdb85c: 0x41414141 0x41414141 0x41414141 0x41414141
0x17bdb86c: 0x41414141 0x41414141 0x41414141 0x41414141
0x17bdb87c: 0x41414141 0x41414141 0x41414141 0x41414141
0x17bdb88c: 0x41414141 0x41414141 0x41414141 0x41414141
0x17bdb89c: 0x41414141 0x41414141 0x41414141 0x41414141
(gdb) x/20x $edx
0xbfffca99: 0x1f000016 0x6c000000 0x00000006 0xa8000000
0xbfffcaa9: 0x0f001201 0x6c92dbbc 0x000083f6 0x5800000c
0xbfffcab9: 0x2517bdcc 0x009494bd 0x00000000 0x08000000
0xbfffcac9: 0x7abfffcb 0x009494bd 0xe0001200 0xa815ae1f
0xbfffcad9: 0x04000001 0x00000400 0x9317b7ba 0xa8175712
(gdb) info registers
eax 0x17bdb85c 398309468
ecx 0x0 0
edx 0xbfffca99 -1073755495
ebx 0x17481708 390600456
esp 0xbfffc910 0xbfffc910
ebp 0xbfffcbc8 0xbfffcbc8
esi 0xffffeae6 -5402
edi 0xbfffcd38 -1073754824
eip 0x17482176 0x17482176 <_enginenotificationproc+2687>
eflags 0x286 646
cs 0x17 23
ss 0x1f 31
ds 0x1f 31
es 0x1f 31
fs 0x0 0
gs 0x37 55
(gdb)

Conclusion

Installing Apple code on a Microsoft Vista system will make that system unsafe. Since these QuickTime vulnerabilities are equally exploitable on both Vista and Mac OS X 10.5, the fans might conclude that both operating systems are equally safe. This is not true, Vista is vastly more secure than the Macintosh. Apple’s only advantage over Microsoft is their small market share, which means hackers are less interested in them. However, as hackers are having a harder time cracking Vista, they are getting more interested in the Mac, and we are seeing more exploits and more malware targeting Apple users.

As always there is more information in the Hacker Eye View report concerining these issuses.

Super Tuesday!!

Today is the Microsoft drop day and it was pretty light. The most dangerous bug is the Active Directory vulnerability. Its a bit hard to weaponize but its doable but I doubt there will be much of a worm. If someone manages to get it working it will more likely be used in directed attacks. Once again this proves how bad ass Neel Mehta is.

Since Errata finished up early today covering these vulns and we know super Tuesday is all any security blog will discuss today, I know present you with videos of Dillon miniguns!




And...

News from Microsoft: DNS 0day being exploited in the wild

http://blogs.technet.com/msrc/archive/2007/04/12/microsoft-security-advisory-935964-posted.aspx

It seems not long ago I use to observe many an argument about if 0day is ever really used in real world attacks. No one really has those fights anymore; I guess the pundits are weary from all the numerous 0day attacks that have popped up in the last few years. I don’t care to go and dig up links to naysayer’s but I am sure the usual suspects like Lindstrom have pie all over their face on the “0day isn’t really used in attack” predictions.

Back to this new bug, it’s in server code so workstation type installations like Windows XP SP2 and Windows 2000 Pro are not affected. Microsoft, of course, doesn’t give details on the flaw or even what people should look for in a potential attack scenario. The only real clue to this is that it involves RPC and that its not vulnerable over port 53. I can hear the sound of people starting IDA all over the world, I know I am. A bit more of a clue to the problem is given in the “Suggested Action” section: creating a registry key can disable the functionality that allows an anonymous remote attack to trigger a stack based overflow. I personally think Microsoft gave out way to much detail here, but time will tell.

The one thing wish Microsoft would tell you is what sector or client profile is being targeted. No sense for people in a University to get all paranoid if the targets have only been Military installations so far. Of course its never a bad thing if everyone is more cautious.

Errata will have an HEV on this for customers pretty soon.

UPDATE: Running DNS.exe through something like Dave Aitel's UNMIDL or using the Tenable IDA plug-in mIDA (pictured below), there isn't a lot of places a bug could be. The SANs ISC diary initially said it was the DCOM exploit over a new port. The arrived at this conclusion because they claimed that the packets matched a Blaster exploit. One of the byte strings they said matched was this: 05 00 0B 03 10 00 00 00 I found this laughable because if you have spent anytime wrangling packets you know exactly what that is. It’s the beginning of a DCERPC BIND request. The 05 is the major version, the 00 is the minor version, 0B is the request type (in this case it’s a BIND, 03 is the flags, and 0x10000000 is data representation (if its little endian or big endian). If you look at a lot of traffic you will notice that this is pretty standard for the beginning of a DCERPC request, and there are tons of reasons you would see this legitimately.

BTW, since this is a RPC based attack you will see plenty of ways to evade most IPSs when they release signatures for this. Based on the ease of finding this you should see publicly available exploits pretty quickly. The question is will the patch be out quickly enough to make this a non-issue for attackers.

UPDATE 2 PER ROB:

One possible signature for intrusion detection would be to simply trigger on the GUID of {50abc2a4-574d-40b3-9d66-ee4fd5fba076}. In a protocol-analysis system, like Proventia, you could simply add that to the blacklisted GUIDs. In a pattern-match system, you can enter something like:

alert tcp any any -> any 1024: (msg:"DNS DCE-RPC exploit emergency rule"; content:"a4 c2 ab 50 4d 57 b3 40 9d 66 ee 4f d5 fb a0 76"; sid:9999; )

Note that the exploit, and its evasions, are a bit more complicated than just this, so you shouldn't rely upon the above pattern signature catching everything.

SANs sticks head in sand over exploits...

http://isc.sans.org/diary.html?storyid=2220

I really don’t understand organizations some times. SANs states they won’t link to the original advisory Solaris telnet. This confuses me because anybody who really wanted to find it would take a few seconds a Google it and come up with a bunch of sites in the blog-o-sphere that list the exploits. I think they are doing this because they don’t want to be accused of distributing exploits but in the end I don’t think they are making their readers any safer. We have all seen/met/worked for the kind of person that would read the SANs entry and declare it FUD and that telnet stays on. This doesn’t occur necessarily because they are clueless, it could just be that that have been dulled by every security vendor pitch in the world claiming that the sky is constantly falling. It would be a different story if no one knew about this but the cat is most definitely out of the bag. I feel this kind of information is required for a company to test and understand the problem themselves. SANs sees fit to deny this to the people who use them as a sole source of security information.

I would like to know how security vendors are responding to this as well. Errata Security shipped a detailed report on the problem including protection mechanism like a snort rule about a few hours after it was on announced in the early hours of a Sunday morning. Can anybody who uses any other security vendor’s comment on their response; a new ruleset, an alert, advisory, anything?

Stop me if you heard this one...So A priest, A rabbi, and Cisco IOS walk into a bar…

Cisco devices running IOS which support voice and are not configured for Session Initiated Protocol (SIP) are vulnerable to a crash under yet to be determined conditions, but isolated to traffic destined to Port 5060. SIP is enabled by default on all Advanced images which support voice and do not contain the fix for CSCsb25337. There are no reports of this vulnerability on the devices which are properly configured for SIP processing. Workarounds exist to mitigate the effects of this problem.

http://www.securityfocus.com/archive/1/458661/30/0/threaded

No really, I can’t buy humor like this. Since my day job is analyzing security problems let me give you readers my professional opinion on this one. In order for Cisco to release an advisory for a “yet to be determined condition” that must mean a very large or several large customers would have to be complaining because their infrastructure is getting hit with this.

Why build a 100,000 botnet army when you can DoS a site with a few packets?

So this might actually be Cisco 0day in the wild! Or it could just be a badly configured SIP client that doesn’t respect the RFC very well that is accidentally bringing down companies. Since the Cisco VoIP solution does not use SIP, it uses SCCP I wonder how many Cisco VoIP solutions are vulnerable to something like this. Of course I am just speculating until I find the problem (and trust me I am looking heavily right now) but its very unusual for Cisco to release an advisory for a problem they can’t pin down yet and since they don’t share security information there isn’t much else that can be done beside run a SIP fuzzer. BTW although they say it later in the post a reload is a spin kind of way of saying this will lead to a denial-of-service attack. Ordinarily DoSes are lame, unless they can stop an entire infrastructure from working, then they become cool.

Errata Security is currently researching this new threat and will alert customers as soon as we have it pinned down.

So let me restate something that seems to be a weekly thing: Diversity is a great way to ensure either a malicious kid or just plain bad software doesn’t bring down your network.

UPDATE: If you are a Cisco customer, ask them why they don't share security information with security vendors. If they try the national security line please roll your eyes.

2007: the year someone will mention 0day to you in a club

Do you remember where you were the first time a layman said something to you about a “virus” or a “worm” and how those “hackers” can take over your “computer”. I do. I was in club; it was 2000 so I was being assaulted by the sounds of N’sync, Pink, Creed, and Macy Gray. Being that I was 22 or so it’s a safe bet that I was wearing a shiny shirt to impress women, it was a very scary time. I was talking to a cute girl in a short skirt (ah the things you remember) who asked me what I did for a living. After telling her I worked with computers she started in on a long story about how those “hackers” tricked her because she got an email with the subject line “I Love you” and she totally fell for it and got a “virus” then her computer crashed. I suddenly felt like my super secret club just became a subject of mainstream discussion.

With Word flaws, and Apple flaws, and a host of other problems affecting people in ways previously unseen, like Myspace, I predict someone will have a similar experience: “Like, I was totally surfing Myspace and some hackers like used one of those 0days on me and now my credit card information is in like Prague or something”.

I remember when it was a hard thing to find 0day and there were so called 0day brokers who were often regarded like underground cyber arms dealers. Not anymore it seems. This morning I awake to a story about Oracle rootkits and 0day. The story revolves around a company in Argentina, Argeniss, which sells a 0day pack for Canvas. Immunity, the makers of Canvas also have their own vulnerability sharing club. Argeniss isn’t the first service of its kind to build an ecosystem around exploit frameworks. Gleg offers up the vulndisco pack which also works on top of Canvas. Not to be confined to exploit framework ecosystmes some vendors like Digital Armaments also sales 0day information. Yours truly, Errata Security, even includes original 0day information in our Hacker Eye View Service. It won’t be long till Gartner has a magic quadrant for 0day services. It’s hardly a secret anymore.

Back to Oracle rootkits. This is not a new problem. Since vendors are hardening their OSes attackers have two options: go up to the application layer or go deep into the device drive layer. We have seen plenty of device driver problems so to make sure the app layer doesn’t feel lonely, we have database rootkits. The first person I saw talk about this was Alexander Kornbrust, A great presentation on this can be found here. Since security is actually all about diligence you now need to add checking databases for rootkits to the list as there is weaponized code available. I doubt it will be long till we see similar rootkits for DB2 or Microsoft’s SQLServer. Anybody have good suggestions for verifying database integrity?

Its Cisco again….again…

It seem like Cisco has rapidly become one of my favorite things to talk about on this blog. Cisco shipped 3 security updates today for a variety of problems. The worst problem, if taken advantage of, could stop a router from passing traffic and could have the potential for code execution. This isn’t good, in fact it’s bad. This should make network engineers who live in Cisco only shops very afraid. Diversify your solutions; it’s the only way to make a survivable network these days.

Errata customers should have access to the briefs on the vulnerabilities with full HEVs coming soon.

The three vulnerabilities are in the handling of TCP packets, IP options, and IPv6 packets. I find this to be a bit humorous because if you don’t know, I worked on the same Advanced Research and Development team as Mike Lynn did while at ISS. In fact we use to all sit in a big room together. The reason all that Cisco research started in 2005 was that Cisco refused to share information on an IPv6 vulnerability that was released in January of ‘05 and here we have another one. With the advances in reverse engineering and the availability of better tools I wouldn’t be at all surprised if someone had and was passing around a Proof-of-Concept for any of these bugs that at least perform a Denial-of-Service.

Again let me state for the record how I feel about this: do not buy a single vendor solution for something as important as the very basis for how your network operates. I know you may get volume discounts or sales reps might take you to nice lunches but eventually something like this will happen. Do you really want to be up all night wondering if your network can be patched faster than hackers can develop a working exploit? And remember, they don't need to get a shell, they just need a DoS to cause havoc.

Cisco alerts.

Interesting and timely post from Halvar about using BinNavi on embedded systems (like IOS).

Oracle HEV

http://www.oracle.com/technology/deploy/security/critical-patch-updates/cpujan2007.html

We have distributed an initial HEV (Hacker Eye View) brief on these vulnerabilities to customers and are working on in-depth analysis for critical issues.

Microsoft Patch Release initial analysis

Microsoft just released their patches; I have to say it’s a pretty lackluster offering. 3 Office bugs and one VML bug.

The break down for critical vulnerabilities is pretty easy: one in excel, one in outlook and one in VML (aka. Internet Explorer).

Excel is not a surprise as the summer and fall saw active targeted 0day exploitation against certain targets. Being that this is a client side vulnerability and malicious attacker wouldn’t have to many opportunities for a retry as unsuccessful exploitation will crash the application. This is important to patch as it will be hard for IPS vendors to guard against this. The Excel file format is so complex the best most vendors can do is add signatures for any proof of concept that arises or their customers will be swimming in false positives. This means all an attacker needs to do is write a new and slightly differing version of the exploit and it should bypass most inline protection tools.

The Outlook bug is exceptionally bad. If you just receive the e-mail, you are owned (even before you open the e-mail or see it in the preview pane). No user interaction is required; this one is also in the category of “patch as soon as possible”. A worm could use this propagate and could result in clogging corporate email servers. Servers who succumb to a spike in email delivery could cause more or a problem than successful exploitation of the end user.

Windows did not escape this month without a fix. This one is in the well worn VML library. This vector is exploitable via a webpage and email. Standard obfuscation methods for web based attacks like a variety of different encoding methods apply. Inline security tools would be hard pressed to detect 100% of VML exploit variants. A similar vulnerability was discovered last year being exploited in the wild.

Active exploitation of all these vulnerabilities will likely include botnet/rootkit malware.

MSRC Advanced Notification & Sales Pitch

http://blogs.technet.com/msrc/archive/2007/01/04/january-2007-advance-notification.aspx

Next week is Microsoft Patch Tuesday and the MSRC released their “Advanced notification” summary. It looks like a total of 8 bugs will be released with some critical issues in the bunch. The patches and advisories are released around 1pm EST.

If you are an Errata Security customer you can expect you initial analysis by 2:30 with full analysis of critical functions following shortly after that. If you don’t know about our service: we tell our customers, and for tier 2 customers provide working exploit code, for what Microsoft told you they patched and even what they didn’t tell you they patched. We also provide expert analysis on the patches: what’s important, what’s not, and what you should drop everything to fix. We do this for almost all major vendor patches and security happenings. Customers also get access to the Errata Security research pipeline, or vulnerabilities we have found in house. Customers are notified at the same time the vendors are.

That’s enough of a sales pitch for now.

It has begun!!

http://applefun.blogspot.com/2007/01/moab-01-01-2007-apple-quicktime-rtsp.html

As much as I would love to take pot shots at Apple, this is actually a serious problem. ErrataSec is currently testing to see how this affects Windows and OSX (because it’s a quicktime bug, it runs on both OSes). Since there has been a lot of interest in bugs like this for hacking through social networking sites you can expect this bug to get some serious play.

The month of Mac bugs has started with a bang!

UPDATE:

http://blog.washingtonpost.com/securityfix/2007/01/quicktime_flaw_kicks_off_month.html

Brian Krebs is covering this as well.