Showing posts with label 0day. Show all posts
Showing posts with label 0day. Show all posts

Sunday, July 14, 2013

Thanks EFF for outlawing code

The EFF has been at the forefront calling cyberweapons "unethical" and "dangerous". As a result of such rhetoric by the EFF and many others, the next NDAA (National Defense Authorization Act for 2014) will likely contain provisions to regulate cyberweapons. The text of the law is at the bottom of this post.

This demonstrates the Orwellian nature of EFF's populism. They don't stand for principle but for popularity. They abandon their principle that the Internet is sovereign when they promoted Net Neutrality. They abandon their principle that code is free speech by suggesting that some code needs to be regulated.

The text of the NDAA, below, calls for the president to implement export controls on code:

 SEC. 946. CONTROL OF THE PROLIFERATION OF CYBER WEAPONS.
(a) Interagency Process for Establishment of Policy- The President shall establish an interagency process to provide for the establishment of an integrated policy to control the proliferation of cyber weapons through unilateral and cooperative export controls, law enforcement activities, financial means, diplomatic engagement, and such other means as the President considers appropriate.
(b) Objectives- The objectives of the interagency process established under subsection (a) shall be as follows:
(1) To identify the types of dangerous software that can and should be controlled through export controls, whether unilaterally or cooperatively with other countries.
(2) To identify the intelligence, law enforcement, and financial sanctions tools that can and should be used to suppress the trade in cyber tools and infrastructure that are or can be used for criminal, terrorist, or military activities while preserving the ability of governments and the private sector to use such tools for legitimate purposes of self-defense.
(3) To establish a statement of principles to control the proliferation of cyber weapons, including principles for controlling the proliferation of cyber weapons that can lead to expanded cooperation and engagement with international partners.
(c) Recommendations- The interagency process established under subsection (a) shall develop, by not later than 270 days after the date of the enactment of this Act, recommendations on means for the control of the proliferation of cyber weapons, including a draft statement of principles and a review of applicable legal authorities.

Thursday, April 16, 2009

Ode to 50cent

I was recently on a plane for a LONG, LONG time. For me this is roughly equivalent to putting a cat in a box and dangling it over water. I get bored easy and after watching all the television shows I had brought with me I decided to play with IDA and any unsuspecting binaries from my laptop that I randomly selected. While doing this I noticed iTunes kept crashing, predictably and reliably in the same place. I decided to use gdb to see what the hubbub was all about. However I got dissed and iTunes would not allow itself to be debugged.



This would not do. Not knowing anything about the anti-debugging capabilities of iTunes I decided the best way (and the laziest way) for a programmer to try and keep me from debugging is ptrace. I set a breakpoint on ptrace and tried it again. I got a nibble. I typed return, and then let iTunes continue on its way. It worked somewhat: it would continue but I was prompted over and over again to complete the same task and if I deleted the breakpoint iTunes would exit. I decided to modify ptrace to return immediately. I did so with the following command:

set *(int)ptrace = 0xc3


0xc3 translated to ret. After I did this I deleted the breakpoint and let iTunes go about its normal activity, or as 50cent would say, “sit back and let the money pile up.”


B00m, we have a crash.

Now I can examine the information from the crash and work on how exploitable the problem is. The exploitability is a post for another day; I just thought some folks could use a nifty trick if they found themselves in a jam.


(This post was written to 50cents “How to rob.” Also I typed some commands in gdb that produced errors becasue my regular alias file was not loaded.)

Thursday, March 26, 2009

New Firefox 0day in WinDBG


Here is a screenshot of the new FF 0day in WinDBG using the !exploitable extension. I am swamped with work right now, when I get a moment I try to post a more detailed writeup.

Monday, December 29, 2008

I am not dead AND guessing redacted documents...

Skip to end for updates on this ongoing speculation....

(All this time without a blog post and this will be a short one. I am sorry I haven’t been posting a lot lately but that is what happens when *GASP* paying customers have to come first.)

Like a lot of other people, I have been speculating about the "internet ending" bug that will be displayed at CCC tomorrow by Alexander Sotirov and Jacob Applebaum. I would like to start by saying that I am not in anyway making fun of them or their findings. These are very smart people, and if they say they can cause problems for internet infrastructure, I am preparing to spend the next few days reading books while the internet is not a safe place.

This post is not really about the bug but the redacted document used as an abstract about the talk. I know a lot of work has been done in the space of reading or making sense of redacted docs in the past, but I am an amateur so I thought I would write about my take. I have no insider info, and anything I say is just a pure guess.

At first look of the document, I noticed two areas that stand out. One is the last redacted statement of the second paragraph, and the second is the first redacted statement of the last paragraph. They both mention infrastructure in a way that implies (at least to me) that the first is a shortened or abbreviated version of the second.



The next thing I did is count the characters in each redacted block. I first printed out the image and went old school on it with pen and paper. I marked the length of each block, making a judgment call about whether the spaces are including in the redaction, and measured a normal text block of the same length and saw how many characters I could come up with. I got roughly 8 for the first one and around 25 for the second one.



Based on the context of the first and second sentence, I assumed that unless the first 8 characters is a proper noun like Google, it would have to be more generic and include something like “the.” I am not ruling the proper noun out BTW, I am just focusing on more generic terms since information about the attack mentions how widespread the attack is.

Some possibilities I came up with while brainstorming on SILC with Nick DePetrillo for the first interesting redacted block:
"the DNS"
"the PKI"
"the SSL"
"the web"
"the SIP"
"the SSH"

I would list Google and VeriSign but based on the sentence structure you would have to make it plural and show ownership, which would put both of them over the character limit. It was also suggested that Akamai would fit but I can’t see a way to take advantage of that without serious DNS manipulation. So, we have it covered with the DNS entry above.

So what is my guess? Based on HD Moores post about how it could reap benefits and the large resource investment leads me to believe it has something to do with PKI (public key cryptography).

There is known, theoretical weakness in PKI. Chinese researchers found they could create hash collisions in SHA-1 using 269 operations. This could probably be done with less than a million machines working for less than 6-months, well within the power of a botnet. The way an attack could work is that hackers create two certificates that hash to the same value. The first would be for "PayPal" (for example) and the second for "Fubar Inc." The certificate authority, such as Verisign, signs the Fubar certificate, thus also signing the fake PayPal certificate. From that point on, the hacker is now PayPal as far as the rest of the world is concerned. It's not just SSL that is vulnerable, but entire trust chains based upon PKI. This could be used to hack into a company's LDAP system, for example, because now you become a trusted member of that system.

UPDATE 1: The fourth paragraph beings with: The main result of our proof of concept attack is that we are in possession of a *redacted*.
I bet they are in possession of a bogus cert for a website that will evaluate correctly. For instance they have created a fake cert for www.paypal.com that when verified by a browser will check out and not throwing up and phishing filters in any of the major browsers.

UPDATE 2: Speech announced titled "MD5 considered harmful today: Creating a rogue CA Certificate"

Monday, January 14, 2008

New Apple Quicktime Problem – UPDATE

On Thursday an advisory was released to several security research mailing lists with an advisory for an unpatched flaw in Quicktime as well as a simple Proof-Of-Concept(PoC). Over the weekend, that simple PoC morphed into a much more robust attack tool. The current PoC, which is really a weaponized attack tool in sheep’s clothing, will cause memory corruption in both Vista and OSX 10.5.

Quicktime has had a rough time recently with a number of flaws putting both Windows and OSX users at risk. You can’t fault them for having flaws in their software, everybody does. The problem I have with Apple is that these attacks would not be exploitable if they took advantage of advanced security features in Vista. This exploit requires an attacker to know a static offset in the process space that they can use to their advantage. Taking advantage of ASLR in Vista would mitigate this risk and keep millions of Windows users safe. In the update form the last problem, ASLR was not enabled and as I have previously shown it is nothing more than changing a bit a QA cycle.

Due to Apples lack of adoption of these features or a secure development cycle, I have recommended to our customers that all Apple software should be removed from Windows machines. That is Quicktime, iTunes, and Safari.

What the exploit looks like running with default options.
The OSX 10.5 crash.

The WinDBbg output on Vista.

Wednesday, November 28, 2007

The thing that makes candy sweet...

UPDATE: RIght after clicking submit I saw this appear. New Quicktime exploit that targets Tiger and Leopard. The list of affected systems from the advisory:
Version: 1.0 (+leopard_ppc +leopard_x86 +tiger_x86 +tiger_ppc +win_xpsp2)

Wow the Macalope shocked Apple fans every with a statement that is reminiscent of hooves on a chalkboard.

You might be surprised to hear the Macalope agree with Maynor, but he's right.
To start with, lets settle that dydl isn’t a library so Apple’s ASLR implementation is just peachy thread in his comments section. ASLR is more than just randomizing libraries. ASLR stands for Address Space Layout Randomization not Library Space Layout Randomization. Libraries are just one piece of the pie that also includes where the stacks and heaps are located and where the executable image gets based. Keep in mind that half implementing ASLR is about as useful as halfway closing a hatch on a submarine while its diving. The new QuickTime RTSP bug proved that by taking advantage of just a few components that are statically loaded in Vista. Therefore, you may get a gold star for effort in the end you can be sure that an exploit writer can take the time to find the overlooked areas.

The Macalope suspects that the free keggers the company throws for security professionals and, well, everyone and their alcoholic mother don't hurt, either.
Ah there is the Macalope we know and love. If somebody says Microsoft did something right they must be bribed. Sorry, that’s not the case, I just think some simple things they have done will increase the overall reliability and safety of their applications. Take the Security Development Lifecycle and its list on banned functions. It not super technical all they did is identify unsafe functions that are hard or impossible to use safely like strcpy, sprintf, and scanf to name a few, and forbid their use. They even developed “safe” versions of the functions that do proper bounds checking and such like strcpy_s. This would have helped prevent the current QuickTime snafu since it was just a simple stack overflow using bcopy incorrectly. This isn't secret Redmond mojo, its just common sense. If it hurts to stick your hand in a fire, don't do it. If programmers can't use functions safely, take away the functions.

Something else Microsoft does that I really think is useful revolves around fixing vulnerabilities. So when they get a vuln report they don’t just fix that problem but also audit the surrounding code and look for additional vulnerabilities. So this RTSP bug is interesting. You may remember MOAB #1, a RTSP buffer overflow in the rtsp address. The current vuln is in an overly long content field. The problems are not directly related but they sure are neighbors. In fact I find it hard to believe you could fix MOAB #1 and not grep the source tree for other potentially bad function use.

Enough about Microsoft, they still have a long way to go. For instance trying to get a security patch for a Windows Mobile device is like trying to land a UFO in a glass of water. That is right UFOs and Windows Mobile security patches both do not exist. I am a big fan of the iPhone because you just plug it in and it will automatically check for updates.

"Vastly" is debatable. The structure is there, Apple just needs to implement it properly. Many of the items Ptacek points out are user-correctible. Apple could be just a dot release away from fixing them if it wanted to.

I stand by the “vastly” statement. You see Apple’s problem in security is not the technology. OSX has a great pedigree with its FreeBSD ties and all these problems previously mentioned are fixable. The problem I see with OS is Apple. Unless I am mistaken the Apple Security team if 4-5 people, or at least it was last year at this time. That is like having one police officer patrol New York City, its ridiculous. You can tell they are understaffed by looking at the patch cycles. An interesting thing to note is that when Microsoft releases patches for their desktop Oses I’ll write PoC samples to see if they could affect Windows Mobile. Why is this important and what does it have to do with patch cycles? OSX ships with a lot of open source software and they occasionally have flaws. Take Samba for instance. Apple shipped Security Update 2007-07 on July 31st (the day before the Blackhat Briefings started) that fixed a number of Samba flaws. The problem is that the Samba project announced the fixes for these flaws in May. That gave resourceful attackers a 3-month window to wreck havoc. The moral of this story is that hackers can take advantage of an understaffed development team just as much as a buffer overflow. I have a list of all open source software that ships with OSX and I pay close attention to any security advisories regarding them. You never know when something innocent can lead to a root compromise.

To continue the Apple Engineer problem sometimes bugs will reappear. Doesn't this look familiar (from the ISC handlers diary). Sure it may be the Japanese version of the software but overly long content type fields are a known problem, why not add a QA test case for simple stuff like that? Or even better, fuzz applications before shipping them.

Apple needs to take security seriously. They need a CSO and they need to stop believing their own press. Take the iPhone, the update features aside I think it has been an abysmal failure in terms of security as exploit after exploit is discovered and released. I think that the iPhone saga illustrates the point that as more people get their hands on OSX the problems will continue to grow.

And that’s all I have to say about that.

Monday, June 11, 2007

Niiiice...

**PLEASE DO NOT POST A COMMENT IF ITS ABOUT SAFARI IN BETA**
These bugs have been verified in the current PRODUCTION copy on OSX (Safari 2.0.4).

Apple just released a Safari for Windows beta at http://www.apple.com/safari. Using publicly available tools we had a DoS in no time. Keeping with our disclosure policy, we do not report bugs to Apple.


UPDATE: Whoops, sorry, thats not a DoS, its memory corruption.

UPDATE 2: Per Request....WinDBG output of a new bug. These are popping out like hotcakes.



UPDATE 3:
It appears I am not the only person who had this idea today?
http://aviv.raffon.net/CommentView,guid,54A1DB79-0ECB-4F13-99AE-45BAB70C4256.aspx#a0ac5417-013d-43ae-9abc-7d265113892c

UPDATE 4: Thor Larholm has also found a bug.
http://larholm.com/2007/06/12/safari-for-windows-0day-exploit-in-2-hours/

I'd like to note that we found a total of 6 bugs in an afternoon, 4 DoS and 2 remote code execution bugs. We have weaponized one of those to be reliable and its diffrent that what Thor has found. I can't speak for anybody else but the bugs found in the beta copy of Safari on Windows work on the production copy on OSX as well (same code base for alot of stuff). The exploit is robust mostly thanks to the lack of any kind of adanced security features in OSX, I write about it here.

UPDATE 5: I've been asked what our disclosure policy is. Its pretty simple, in most cases we will give vendors as long as they need to fix problems. If the vendor is unresponsive or make threats, we will give them 30 days then release details. If a vendor answers a vulnerability disclosure with marketing and spin attempts, we no longer report vulnerabilities to that vendor but the information goes into our Hacker Eye View program for customers and will be used in pentesting. We do not sell the vulnerabilities to any 3rd party.








Tuesday, May 01, 2007

Apple Update

http://www.zerodayinitiative.com/advisories/ZDI-07-023.html

The Cansec Apple bug is out. Apple got this done in 8 days which is not to bad.

Monday, April 30, 2007

Wireless NAC != Wireless IPS: AirTight...Leaks...

Rob Graham and I came in contact with some Airtight boxes. In case you don't know they are a maker of wireless IDS technology. Since we know a thing or two about wireless we wanted to look and see how these boxes work and if the perform as advertised. If you don't want to read the entire blog post the short answer is: not completely. In our quick peek we found 3 problems. If we were doing a real assessment we would have pulled out the screw drivers and, ICE gear, and disassembler but instead we looked at this from a blackbox remote perspective.

Problem 1: Protection relies on you being a good citizen.
One of the most touted features is the ability to shutdown rogue access points and give administrators the ability to control who has access points and who doesn't and which ones are legitimate and which ones are not. This is done by detecting the access point, determining if it is legitimate and then flooding it with deauthentication packets if it isn't. It does this by spoofing deauthentication packets in both directions from the user to the access point and from the access point to the user (Packet caps of this to the right). These packets are in the standard and are basically there to say "go away, I am not interested in working with you". So I am sure you are curious what happens if you modify you driver and an access point to ignore these types of packets? Nothing, you can just keep humming away and do whatever it is you want to. Now the argument we heard when we originally mentioned this to people is that these types of devices are not designed to stop determined attackers, just a clueless guy who plugs in a Linksys in accounting and those guys don't use custom wifi drivers. To bad, we do, and this company would have failed a penetration test. Relying on a remote attacker to adhere to a standard for your security too to work is crazy, that's as bad as the Cisco Security Agent API hooking that relied on you executing jumps to its analysis engine to work properly. In the Cisco case and the Airtight case you can just ignore the spec and the security breaks down.
Problem 2: Slowdown
We looked at how these devices would detect new access points. I thought at first it would be done via a combination of beacon and probe response to verify they were real access points but we noticed something. The device would detect the access point from what appear to be probe response packets and then one of their sensors would spoof a packet to be transmitted through the access point to itself. If it received the packet then it would know the access point is indeed on the network. So what happens if you generate hundreds of thousands of fake probe responses? There is such a slow down in responding to them that you could actually go about your normal business of plugging in a rogue access point and letting people external to your offices have access to you network before the sensors will actually detect it and start blocking it. Saturating it with about 10,000 fake probe responses meant that we would have between 1:30 minutes and 3:30 minutes before Airtight realized our access point had appeared. This may not seem like a lot but if you are trying to copy things out unseen or quickly infect a company with a worm, that all the time you need. We didn’t spoof for very long, but it appeared that if we left it running, we’d eventually fill up the database and take down the system.
Problem 3: It really does leak
In problem 2 it was noted to verify that an access point is actually on the network a sensor would spoof a packet to be transmitted through the access point and if it was received by the sensor the containment process would begin by generating fake deauthentication messages. This is a problem because it leaks information about your internal network. This method of determining whether or not an access point is on the network means that UDP packets are being generated with the internal IP address of not just the sensor sending the spoofed packets but also the management console and sending them over sniffable wireless access for all to see and capture. So even if you are not on the network and just sniffing the channel the AP is on you can get information on that company's internal network information like addressing scheme and layout; you could even write a snort rule to detect just these types of packets.. Thank you very much! With the work that has been done on Ferret we have become hyper sensitive to unintentional information leaks and this is definitely one.

Verdict: Great for clueless folks but will not keep out a skilled attacker
While these boxes may keep Bob from accounting from buying an access point at lunch and sharing your network to the world, they will not stop and in some cases aid a determined attacker in compromising your enterprise. They should not be labeled either "intrusion detection" or "intrusion prevention". These devices have no ability to stop a driver level attack like the ones we have previously discussed.
Also I hate recreating other peoples work. After we found these problems I was pointed to the paper below that contains information about the deauth problems. It has a far more in-depth review of the weaknesses and why most of these products just don't add up.http://802.11ninja.net/~jwright/802/papers/wlan-sess-cont.pdf


Wednesday, April 25, 2007

Tom at Matasano reported this following alarming message:
http://www.matasano.com/log/840/urgent-turn-off-java-in-your-browser/

So disable Java...

Monday, April 23, 2007

UPDATE: I have gotten many questions about this post...and the answer is...If I can do this...why can't Apple and Firefox?

After the announcement this weekend about the Dino Safari exploit I decided to take some publicly available tools for a test drive. Below is the result of running HD Moore’s Hamachi tool. BTW, HD is a rock star and I wish I could take him to the prom.

If you think its biased running the same test on firefox results in a DoS. I doubt this is the bug Dino exploited because in the .05 seconds I spent looking at this bug it looks like a DoS.

**********

Host Name: david-maynors-computer-3
Date/Time: 2007-04-23 10:46:22.885 -0400
OS Version: 10.4.9 (Build 8P2137)
Report Version: 4

Command: Safari
Path: /Applications/Safari.app/Contents/MacOS/Safari
Parent: WindowServer [96]

Version: 2.0.4 (419.3)
Build Version: 7
Project Name: WebBrowser
Source Version: 4190300

PID: 299
Thread: 0

Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0000000c

Thread 0 Crashed:
0 com.apple.WebCore 0x95456842 DOM::NamedAttrMapImpl::setNamedItem(DOM::NodeImpl*, int&) + 70
1 com.apple.WebCore 0x954bdc00 DOM::Element::setAttributeNodeNS(DOM::Attr const&) + 142
2 com.apple.WebCore 0x954bdcb0 DOM::Element::setAttributeNode(DOM::Attr const&) + 32
3 com.apple.WebCore 0x953bc5f2 KJS::DOMElementProtoFunc::tryCall(KJS::ExecState*, KJS::Object&, KJS::List const&) + 1740
4 com.apple.WebCore 0x95343909 KJS::DOMFunction::call(KJS::ExecState*, KJS::Object&, KJS::List const&) + 65
5 com.apple.JavaScriptCore 0x9523077e KJS::Object::call(KJS::ExecState*, KJS::Object&, KJS::List const&) + 158
6 com.apple.JavaScriptCore 0x9522f72d KJS::FunctionCallNode::evaluate(KJS::ExecState*) + 533
7 com.apple.JavaScriptCore 0x9522f509 KJS::AssignExprNode::evaluate(KJS::ExecState*) + 35
8 com.apple.JavaScriptCore 0x9522f420 KJS::VarDeclNode::evaluate(KJS::ExecState*) + 80
9 com.apple.JavaScriptCore 0x9522f370 KJS::VarDeclListNode::evaluate(KJS::ExecState*) + 56
10 com.apple.JavaScriptCore 0x9522f222 KJS::VarStatementNode::execute(KJS::ExecState*) + 94
11 com.apple.JavaScriptCore 0x9522f072 KJS::SourceElementsNode::execute(KJS::ExecState*) + 252
12 com.apple.JavaScriptCore 0x9522ef32 KJS::BlockNode::execute(KJS::ExecState*) + 102
13 com.apple.JavaScriptCore 0x9523aac9 KJS::GlobalFuncImp::call(KJS::ExecState*, KJS::Object&, KJS::List const&) + 1093
14 com.apple.JavaScriptCore 0x9523077e KJS::Object::call(KJS::ExecState*, KJS::Object&, KJS::List const&) + 158
15 com.apple.JavaScriptCore 0x9522f72d KJS::FunctionCallNode::evaluate(KJS::ExecState*) + 533
16 com.apple.JavaScriptCore 0x952353ec KJS::ExprStatementNode::execute(KJS::ExecState*) + 76
17 com.apple.JavaScriptCore 0x9522f072 KJS::SourceElementsNode::execute(KJS::ExecState*) + 252
18 com.apple.JavaScriptCore 0x9522ef32 KJS::BlockNode::execute(KJS::ExecState*) + 102
19 com.apple.JavaScriptCore 0x95255476 KJS::TryNode::execute(KJS::ExecState*) + 216
20 com.apple.JavaScriptCore 0x9522f147 KJS::SourceElementsNode::execute(KJS::ExecState*) + 465
21 com.apple.JavaScriptCore 0x9522ef32 KJS::BlockNode::execute(KJS::ExecState*) + 102
22 com.apple.JavaScriptCore 0x9523a5ce KJS::IfNode::execute(KJS::ExecState*) + 344
23 com.apple.JavaScriptCore 0x9522f072 KJS::SourceElementsNode::execute(KJS::ExecState*) + 252
24 com.apple.JavaScriptCore 0x9522ef32 KJS::BlockNode::execute(KJS::ExecState*) + 102
25 com.apple.JavaScriptCore 0x9523f3f1 KJS::ForInNode::execute(KJS::ExecState*) + 1021
26 com.apple.JavaScriptCore 0x9522f072 KJS::SourceElementsNode::execute(KJS::ExecState*) + 252
27 com.apple.JavaScriptCore 0x9522ef32 KJS::BlockNode::execute(KJS::ExecState*) + 102
28 com.apple.JavaScriptCore 0x9523be83 KJS::DeclaredFunctionImp::execute(KJS::ExecState*) + 45
29 com.apple.JavaScriptCore 0x9523b9ba KJS::FunctionImp::call(KJS::ExecState*, KJS::Object&, KJS::List const&) + 458
30 com.apple.JavaScriptCore 0x9523077e KJS::Object::call(KJS::ExecState*, KJS::Object&, KJS::List const&) + 158
31 com.apple.JavaScriptCore 0x9522f72d KJS::FunctionCallNode::evaluate(KJS::ExecState*) + 533
32 com.apple.JavaScriptCore 0x952353ec KJS::ExprStatementNode::execute(KJS::ExecState*) + 76
33 com.apple.JavaScriptCore 0x9522f147 KJS::SourceElementsNode::execute(KJS::ExecState*) + 465
34 com.apple.JavaScriptCore 0x9522ef32 KJS::BlockNode::execute(KJS::ExecState*) + 102
35 com.apple.JavaScriptCore 0x9523a5ce KJS::IfNode::execute(KJS::ExecState*) + 344
36 com.apple.JavaScriptCore 0x9522f147 KJS::SourceElementsNode::execute(KJS::ExecState*) + 465
37 com.apple.JavaScriptCore 0x9522ef32 KJS::BlockNode::execute(KJS::ExecState*) + 102
38 com.apple.JavaScriptCore 0x9523f3f1 KJS::ForInNode::execute(KJS::ExecState*) + 1021
39 com.apple.JavaScriptCore 0x9522f147 KJS::SourceElementsNode::execute(KJS::ExecState*) + 465
40 com.apple.JavaScriptCore 0x9522ef32 KJS::BlockNode::execute(KJS::ExecState*) + 102
41 com.apple.JavaScriptCore 0x9523be83 KJS::DeclaredFunctionImp::execute(KJS::ExecState*) + 45
42 com.apple.JavaScriptCore 0x9523b9ba KJS::FunctionImp::call(KJS::ExecState*, KJS::Object&, KJS::List const&) + 458
43 com.apple.JavaScriptCore 0x9523077e KJS::Object::call(KJS::ExecState*, KJS::Object&, KJS::List const&) + 158
44 com.apple.JavaScriptCore 0x9522f72d KJS::FunctionCallNode::evaluate(KJS::ExecState*) + 533
45 com.apple.JavaScriptCore 0x952353ec KJS::ExprStatementNode::execute(KJS::ExecState*) + 76
46 com.apple.JavaScriptCore 0x9522f147 KJS::SourceElementsNode::execute(KJS::ExecState*) + 465
47 com.apple.JavaScriptCore 0x9522ef32 KJS::BlockNode::execute(KJS::ExecState*) + 102
48 com.apple.JavaScriptCore 0x9523be83 KJS::DeclaredFunctionImp::execute(KJS::ExecState*) + 45
49 com.apple.JavaScriptCore 0x9523b9ba KJS::FunctionImp::call(KJS::ExecState*, KJS::Object&, KJS::List const&) + 458
50 com.apple.JavaScriptCore 0x9523077e KJS::Object::call(KJS::ExecState*, KJS::Object&, KJS::List const&) + 158
51 com.apple.JavaScriptCore 0x9522f72d KJS::FunctionCallNode::evaluate(KJS::ExecState*) + 533
52 com.apple.JavaScriptCore 0x952353ec KJS::ExprStatementNode::execute(KJS::ExecState*) + 76
53 com.apple.JavaScriptCore 0x9522f072 KJS::SourceElementsNode::execute(KJS::ExecState*) + 252
54 com.apple.JavaScriptCore 0x9522ef32 KJS::BlockNode::execute(KJS::ExecState*) + 102
55 com.apple.JavaScriptCore 0x9523be83 KJS::DeclaredFunctionImp::execute(KJS::ExecState*) + 45
56 com.apple.JavaScriptCore 0x9523b9ba KJS::FunctionImp::call(KJS::ExecState*, KJS::Object&, KJS::List const&) + 458
57 com.apple.JavaScriptCore 0x9523077e KJS::Object::call(KJS::ExecState*, KJS::Object&, KJS::List const&) + 158
58 com.apple.WebCore 0x9541f924 KJS::JSAbstractEventListener::handleEvent(DOM::Event&, bool) + 476
59 com.apple.WebCore 0x95350c5a DOM::NodeImpl::handleLocalEvents(DOM::EventImpl*, bool) + 188
60 com.apple.WebCore 0x95350958 DOM::NodeImpl::dispatchGenericEvent(DOM::EventImpl*, int&) + 386
61 com.apple.WebCore 0x953506c6 DOM::NodeImpl::dispatchEvent(DOM::EventImpl*, int&, bool) + 114
62 com.apple.WebCore 0x954583fd DOM::NodeImpl::dispatchMouseEvent(QMouseEvent*, int, int, bool) + 529
63 com.apple.WebCore 0x953943f5 khtml::RenderFormElement::slotClicked() + 105
64 com.apple.WebCore 0x9531a4c5 KWQSignal::call() const + 101
65 com.apple.WebCore 0x95396639 QButton::clicked() + 103
66 com.apple.AppKit 0x9336cd88 -[NSApplication sendAction:to:from:] + 107
67 com.apple.Safari 0x0002b083 0x1000 + 172163
68 com.apple.AppKit 0x9336cce1 -[NSControl sendAction:to:] + 101
69 com.apple.AppKit 0x9336ee91 -[NSCell _sendActionFrom:] + 168
70 com.apple.AppKit 0x93381671 -[NSCell trackMouse:inRect:ofView:untilMouseUp:] + 1271
71 com.apple.AppKit 0x9339f25d -[NSButtonCell trackMouse:inRect:ofView:untilMouseUp:] + 848
72 com.apple.AppKit 0x9339eb0d -[NSControl mouseDown:] + 757
73 com.apple.WebCore 0x953e3526 -[KWQButton mouseDown:] + 68
74 com.apple.WebCore 0x95393d16 KWQKHTMLPart::passWidgetMouseDownEventToWidget(QWidget*) + 662
75 com.apple.WebCore 0x9536fcd3 KWQKHTMLPart::passWidgetMouseDownEventToWidget(khtml::MouseEvent*) + 193
76 com.apple.WebCore 0x9536fb16 KWQKHTMLPart::khtmlMousePressEvent(khtml::MousePressEvent*) + 190
77 com.apple.WebCore 0x954fc5f8 KParts::Part::event(QEvent*) + 24
78 com.apple.WebCore 0x9536f43d KHTMLView::viewportMousePressEvent(QMouseEvent*) + 651
79 com.apple.WebCore 0x9536f0a1 KWQKHTMLPart::mouseDown(NSEvent*) + 511
80 com.apple.WebKit 0x95152a71 -[WebHTMLView mouseDown:] + 225
81 com.apple.AppKit 0x9335c3af -[NSWindow sendEvent:] + 5279
82 com.apple.Safari 0x000230c6 0x1000 + 139462
83 com.apple.AppKit 0x9334e350 -[NSApplication sendEvent:] + 5023
84 com.apple.Safari 0x00022c56 0x1000 + 138326
85 com.apple.AppKit 0x93278dfe -[NSApplication run] + 547
86 com.apple.AppKit 0x9326cd2f NSApplicationMain + 573
87 com.apple.Safari 0x0005f54a 0x1000 + 386378
88 com.apple.Safari 0x0005f471 0x1000 + 386161

Thread 1:
0 libSystem.B.dylib 0x90009bf7 mach_msg_trap + 7
1 com.apple.CoreFoundation 0x9082e2b3 CFRunLoopRunSpecific + 2014
2 com.apple.CoreFoundation 0x9082dace CFRunLoopRunInMode + 61
3 com.apple.Foundation 0x9281cd3a -[NSRunLoop runMode:beforeDate:] + 182
4 com.apple.Foundation 0x9281cc36 -[NSRunLoop run] + 75
5 com.apple.WebKit 0x95130529 +[WebFileDatabase _syncLoop:] + 198
6 com.apple.Foundation 0x927e72e0 forkThreadForFunction + 123
7 libSystem.B.dylib 0x90024147 _pthread_body + 84

Thread 2:
0 libSystem.B.dylib 0x90009bf7 mach_msg_trap + 7
1 com.apple.CoreFoundation 0x9082e2b3 CFRunLoopRunSpecific + 2014
2 com.apple.CoreFoundation 0x9082dace CFRunLoopRunInMode + 61
3 com.apple.Foundation 0x9281ca0f +[NSURLConnection(NSURLConnectionInternal) _resourceLoadLoop:] + 259
4 com.apple.Foundation 0x927e72e0 forkThreadForFunction + 123
5 libSystem.B.dylib 0x90024147 _pthread_body + 84

Thread 3:
0 libSystem.B.dylib 0x90009bf7 mach_msg_trap + 7
1 com.apple.CoreFoundation 0x9082e2b3 CFRunLoopRunSpecific + 2014
2 com.apple.CoreFoundation 0x9082dace CFRunLoopRunInMode + 61
3 com.apple.Foundation 0x92843bc2 +[NSURLCache _diskCacheSyncLoop:] + 206
4 com.apple.Foundation 0x927e72e0 forkThreadForFunction + 123
5 libSystem.B.dylib 0x90024147 _pthread_body + 84

Thread 4:
0 libSystem.B.dylib 0x9001a0ec select + 12
1 libSystem.B.dylib 0x90024147 _pthread_body + 84

Thread 5:
0 libSystem.B.dylib 0x900247e7 semaphore_wait_signal_trap + 7
1 com.apple.Foundation 0x9283d26c -[NSConditionLock lockWhenCondition:] + 39
2 com.apple.Syndication 0x9a6be966 -[AsyncDB _run:] + 181
3 com.apple.Foundation 0x927e72e0 forkThreadForFunction + 123
4 libSystem.B.dylib 0x90024147 _pthread_body + 84

Thread 0 crashed with X86 Thread State (32-bit):
eax: 0x00000000 ebx: 0x9545680a ecx: 0x00000000 edx: 0x14aee000
edi: 0xbfffd164 esi: 0x14c2db88 ebp: 0xbfffd138 esp: 0xbfffd0f0
ss: 0x0000001f efl: 0x00010246 eip: 0x95456842 cs: 0x00000017
ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037

Binary Images Description:
0x1000 - 0xdbfff com.apple.Safari 2.0.4 (419.3) /Applications/Safari.app/Contents/MacOS/Safari
0x5f3000 - 0x5f4fff com.apple.textencoding.unicode 2.1 /System/Library/TextEncodings/Unicode Encodings.bundle/Contents/MacOS/Unicode Encodings
0x15834000 - 0x15d57fff com.macromedia.Flash Player.plugin 9.0.28 (1.0.4f22) /Library/Internet Plug-Ins/Flash Player.plugin/Contents/MacOS/Flash Player
0x8fe00000 - 0x8fe4afff dyld 46.12 /usr/lib/dyld
0x90000000 - 0x90172fff libSystem.B.dylib /usr/lib/libSystem.B.dylib
0x901c2000 - 0x901c4fff libmathCommon.A.dylib /usr/lib/system/libmathCommon.A.dylib
0x901c6000 - 0x90203fff com.apple.CoreText 1.1.2 (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreText.framework/Versions/A/CoreText
0x9022a000 - 0x90300fff ATS /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS
0x90320000 - 0x90775fff com.apple.CoreGraphics 1.258.61 (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics
0x9080c000 - 0x908d4fff com.apple.CoreFoundation 6.4.7 (368.28) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x90912000 - 0x90912fff com.apple.CoreServices 10.4 (???) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
0x90914000 - 0x90a07fff libicucore.A.dylib /usr/lib/libicucore.A.dylib
0x90a57000 - 0x90ad6fff libobjc.A.dylib /usr/lib/libobjc.A.dylib
0x90aff000 - 0x90b63fff libstdc++.6.dylib /usr/lib/libstdc++.6.dylib
0x90bd2000 - 0x90bd9fff libgcc_s.1.dylib /usr/lib/libgcc_s.1.dylib
0x90bde000 - 0x90c51fff com.apple.framework.IOKit 1.4.6 (???) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
0x90c66000 - 0x90c78fff libauto.dylib /usr/lib/libauto.dylib
0x90c7e000 - 0x90f24fff com.apple.CoreServices.CarbonCore 682.18 /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
0x90f67000 - 0x90fcffff com.apple.CoreServices.OSServices 4.1 /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
0x91007000 - 0x91045fff com.apple.CFNetwork 129.20 /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
0x91058000 - 0x91068fff com.apple.WebServices 1.1.3 (1.1.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/WebServicesCore.framework/Versions/A/WebServicesCore
0x91073000 - 0x910f1fff com.apple.SearchKit 1.0.5 /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
0x91126000 - 0x91144fff com.apple.Metadata 10.4.4 (121.36) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
0x91150000 - 0x9115efff libz.1.dylib /usr/lib/libz.1.dylib
0x91161000 - 0x91300fff com.apple.security 4.5.2 (29774) /System/Library/Frameworks/Security.framework/Versions/A/Security
0x913fe000 - 0x91406fff com.apple.DiskArbitration 2.1.1 /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
0x9140d000 - 0x91433fff com.apple.SystemConfiguration 1.8.6 /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
0x91445000 - 0x9144cfff libbsm.dylib /usr/lib/libbsm.dylib
0x91450000 - 0x914c6fff com.apple.audio.CoreAudio 3.0.4 /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
0x91517000 - 0x91517fff com.apple.ApplicationServices 10.4 (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
0x91519000 - 0x91544fff com.apple.AE 314 (313) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
0x91557000 - 0x9162bfff com.apple.ColorSync 4.4.9 /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync
0x91666000 - 0x916d9fff com.apple.print.framework.PrintCore 4.6 (177.13) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore
0x91707000 - 0x917b0fff com.apple.QD 3.10.24 (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD
0x917d6000 - 0x91821fff com.apple.HIServices 1.5.2 (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices
0x91840000 - 0x91856fff com.apple.LangAnalysis 1.6.3 /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis
0x91862000 - 0x9187cfff com.apple.FindByContent 1.5 /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/FindByContent.framework/Versions/A/FindByContent
0x91886000 - 0x918c3fff com.apple.LaunchServices 182 /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
0x918d7000 - 0x918e3fff com.apple.speech.synthesis.framework 3.5 /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis
0x918ea000 - 0x91929fff com.apple.ImageIO.framework 1.5.4 /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO
0x9193c000 - 0x919eefff libcrypto.0.9.7.dylib /usr/lib/libcrypto.0.9.7.dylib
0x91a34000 - 0x91a4afff libcups.2.dylib /usr/lib/libcups.2.dylib
0x91a4f000 - 0x91a6dfff libJPEG.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib
0x91a72000 - 0x91ad1fff libJP2.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib
0x91ae3000 - 0x91ae7fff libGIF.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib
0x91ae9000 - 0x91b6dfff libRaw.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libRaw.dylib
0x91b71000 - 0x91baefff libTIFF.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
0x91bb4000 - 0x91bcefff libPng.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
0x91bd3000 - 0x91bd5fff libRadiance.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib
0x91bd7000 - 0x91cb5fff libxml2.2.dylib /usr/lib/libxml2.2.dylib
0x91cd2000 - 0x91cd2fff com.apple.Accelerate 1.3.1 (Accelerate 1.3.1) /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
0x91cd4000 - 0x91d62fff com.apple.vImage 2.5 /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
0x91d69000 - 0x91d69fff com.apple.Accelerate.vecLib 3.3.1 (vecLib 3.3.1) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
0x91d6b000 - 0x91dc4fff libvMisc.dylib /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
0x91dcd000 - 0x91df1fff libvDSP.dylib /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
0x91df9000 - 0x92202fff libBLAS.dylib /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
0x9223c000 - 0x925f0fff libLAPACK.dylib /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
0x9261d000 - 0x9270afff libiconv.2.dylib /usr/lib/libiconv.2.dylib
0x9270c000 - 0x92789fff com.apple.DesktopServices 1.3.6 /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
0x927ca000 - 0x929fafff com.apple.Foundation 6.4.8 (567.29) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
0x92b14000 - 0x92b2bfff libGL.dylib /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
0x92b36000 - 0x92b8efff libGLU.dylib /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib
0x92ba2000 - 0x92ba2fff com.apple.Carbon 10.4 (???) /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
0x92ba4000 - 0x92bb4fff com.apple.ImageCapture 3.0.4 /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture
0x92bc3000 - 0x92bcbfff com.apple.speech.recognition.framework 3.6 /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition
0x92bd1000 - 0x92bd6fff com.apple.securityhi 2.0.1 (24742) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI
0x92bdc000 - 0x92c6dfff com.apple.ink.framework 101.2.1 (71) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink
0x92c81000 - 0x92c84fff com.apple.help 1.0.3 (32.1) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help
0x92c87000 - 0x92ca5fff com.apple.openscripting 1.2.5 (???) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting
0x92cb7000 - 0x92cbdfff com.apple.print.framework.Print 5.2 (192.4) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print
0x92cc3000 - 0x92d26fff com.apple.htmlrendering 66.1 (1.1.3) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HTMLRendering.framework/Versions/A/HTMLRendering
0x92d4a000 - 0x92d8bfff com.apple.NavigationServices 3.4.4 (3.4.3) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/NavigationServices.framework/Versions/A/NavigationServices
0x92db2000 - 0x92dbffff com.apple.audio.SoundManager 3.9.1 /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CarbonSound.framework/Versions/A/CarbonSound
0x92dc6000 - 0x92dcbfff com.apple.CommonPanels 1.2.3 (73) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels
0x92dd0000 - 0x930c5fff com.apple.HIToolbox 1.4.9 (???) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
0x931cb000 - 0x931d6fff com.apple.opengl 1.4.16 /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
0x931db000 - 0x931f6fff com.apple.DirectoryService.Framework 3.2 /System/Library/Frameworks/DirectoryService.framework/Versions/A/DirectoryService
0x93266000 - 0x93266fff com.apple.Cocoa 6.4 (???) /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
0x93268000 - 0x9391efff com.apple.AppKit 6.4.8 (824.42) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
0x93c9f000 - 0x93d1afff com.apple.CoreData 91 (92.1) /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
0x93d53000 - 0x93e0dfff com.apple.audio.toolbox.AudioToolbox 1.4.5 /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
0x93e50000 - 0x93e50fff com.apple.audio.units.AudioUnit 1.4.2 /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
0x93e52000 - 0x94013fff com.apple.QuartzCore 1.4.12 /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
0x94059000 - 0x9409afff libsqlite3.0.dylib /usr/lib/libsqlite3.0.dylib
0x940a2000 - 0x940dcfff libGLImage.dylib /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib
0x940e1000 - 0x940f2fff com.apple.CoreVideo 1.4 /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
0x94188000 - 0x941c6fff com.apple.vmutils 4.0.2 (93.1) /System/Library/PrivateFrameworks/vmutils.framework/Versions/A/vmutils
0x9420a000 - 0x9421bfff com.apple.securityfoundation 2.2.1 (28150) /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation
0x94229000 - 0x94267fff com.apple.securityinterface 2.2.1 (27695) /System/Library/Frameworks/SecurityInterface.framework/Versions/A/SecurityInterface
0x94283000 - 0x94292fff libCGATS.A.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGATS.A.dylib
0x94299000 - 0x942a4fff libCSync.A.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib
0x942f0000 - 0x9430afff libRIP.A.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib
0x94310000 - 0x945cefff com.apple.QuickTime 7.1.5 /System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime
0x94732000 - 0x94878fff com.apple.AddressBook.framework 4.0.4 (485.1) /System/Library/Frameworks/AddressBook.framework/Versions/A/AddressBook
0x94904000 - 0x94913fff com.apple.DSObjCWrappers.Framework 1.1 /System/Library/PrivateFrameworks/DSObjCWrappers.framework/Versions/A/DSObjCWrappers
0x9491a000 - 0x94943fff com.apple.LDAPFramework 1.4.2 (69.1.1) /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP
0x94949000 - 0x94958fff libsasl2.2.dylib /usr/lib/libsasl2.2.dylib
0x9495c000 - 0x94981fff libssl.0.9.7.dylib /usr/lib/libssl.0.9.7.dylib
0x9498d000 - 0x949aafff libresolv.9.dylib /usr/lib/libresolv.9.dylib
0x9512e000 - 0x951c0fff com.apple.WebKit 419 /System/Library/Frameworks/WebKit.framework/Versions/A/WebKit
0x9521a000 - 0x9529cfff com.apple.JavaScriptCore 418.3 /System/Library/Frameworks/WebKit.framework/Versions/A/Frameworks/JavaScriptCore.framework/Versions/A/JavaScriptCore
0x952d5000 - 0x955b4fff com.apple.WebCore 418.21 /System/Library/Frameworks/WebKit.framework/Versions/A/Frameworks/WebCore.framework/Versions/A/WebCore
0x95733000 - 0x95756fff libxslt.1.dylib /usr/lib/libxslt.1.dylib
0x97403000 - 0x97417fff com.apple.audio.CoreAudioKit 1.0.1 /System/Library/Frameworks/CoreAudioKit.framework/Versions/A/CoreAudioKit
0x9a6bc000 - 0x9a6f3fff com.apple.Syndication 1.0.6 (54) /System/Library/PrivateFrameworks/Syndication.framework/Versions/A/Syndication
0x9a70f000 - 0x9a721fff com.apple.SyndicationUI 1.0.6 (54) /System/Library/PrivateFrameworks/SyndicationUI.framework/Versions/A/SyndicationUI

Friday, April 13, 2007

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.

Tuesday, April 03, 2007

Why did the ANI patch take so long?

Microsoft made us all laugh with the comment in their blog about the ANI patch:
I'm sure one question in people's minds is how we're able to release an update for this issue so quickly


Um, no, the question in everybody's mind was why it took so long.

Actually, there is an answer why it took so long. As documented, there was a bug with a RealTek audio control panel. Even if Microsoft makes ZERO code changes, simply rebuilding the product will lead to bugs like this, either within Windows itself, or 3rd party drivers, applications, or control panels. This bug happened because of something wrong in RealTek's code, not Microsoft's code.

Few people realize this but when Microsoft tests a patch prior to shipping, they also test popular third party applications. They find conflicts due to other people's code. When they encounter such an issue, they change their patch until the 3rd party bug no longer appears. In some cases, they have changed the Windows specification just to fix some weirdness in a popular application. Microsoft doesn't like to talk about this because they don't want to insult other people, but this sort of thing happens a lot. What appears to be "Microsoft's fault" is actually Microsoft covering for other vendors.

Everybody complains that Microsoft takes a week to ship a bug fix for an actively exploited bug, but the fact that they can test 30 different versions of Windows (various patch levels, 2k/XP/2003/Vista, Itanium/x86/x64) and thousands of apps on top of that in under a week is simply amazing.

Many in the community don't think such thorough testing is needed. However, there is a good chance that cost to those running RealTek audio because of this bug will be greater than the cost to those getting exploited. The reason others can create pseudo-patches for such bugs is the don't have to suffer the consequences when it causes more problems for a customer than it solves. Since this QA process is so long, Microsoft tries to schedule when it fixes bugs, so that they can test many of them all at once, rather than retesting every time.

On the other hand, I'm not sure if Microsoft's timeline is shrinking The time between when a developer checks in and the patch ships to customers should be a measured part of a "secure development lifecycle" - and it should be continuously shrinking. No matter how big the problem, engineers shouldn't be making excuses for why it takes so long. For example, instead of rebuilding the affected DLL, maybe Microsoft should instead "patch" it: overwrite a 'jmp' instruction in the affected area to some dead padding area in the DLL that contains the fix, then 'jmp' back. Or do something else: there is always a clever way to solve problems. I'm curious whether (a) Microsoft has been tracking this time-to-patch, and (b) whether it's been shrinking or growing, and (c) whether they are doing researching on fixing bugs other than rebuilding the affected files.

Monday, April 02, 2007

ANI 0day vs. intrusion detection providers

Most people do not know how intrusion-detection systems work. The recent Microsoft 0day animated-cursor/ANI vulnerability is a good way to learn what's really going on. Most intrusion-detections systems had 0day detection for this vulnerability, and were therefore detecting the 'unknown' attacks before everyone else knew about them.

The reason a product could detect this is because signatures are usually based on vulnerabilities rather than exploits. This new bug is essentially the same as an earlier bug in 2005, so the old sigs could detect the new variant of 2007.

Understanding vulnerability-based signatures starts with understanding the vulnerability itself. Animated-cursors are generic Microsoft multimedia files like .avi and .wav. The animation information is contained in a subsection starting with the string "anih". That string is followed by a structure
that looks like:

struct tagANIHeader {
DWORD cbSizeOf; // Num bytes in AniHeader (36 bytes)
DWORD cFrames; // Number of unique Icons in this cursor
DWORD cSteps; // Number of Blits before the animation cycles
DWORD cx, cy; // reserved, must be zero.
DWORD cBitCount, cPlanes; // reserved, must be zero.
DWORD JifRate; // Default Jiffies (1/60th of a second) if rate chunk not present.
DWORD flags; // Animation Flag (see AF_ constants)
} ANIHeader;

This structure contains nine 4-byte values, so the length field should always be exactly 36 bytes. The vulnerability is an unchecked stack overflow from code that looks like:
ANIHEADER anihdr;
memcpy(&anihdr, p+4, *(DWORD*)p);

Signatures for this vuln work by looking for the "anih" section then testing the length field to see it is longer than 36 bytes. The follow is an edited signature from the Snort intrusion-detection system that was written for the 2005 bug that also detects the 2007 variant:

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (\
msg:"WEB-CLIENT Microsoft ANI file parsing overflow";\
content:"RIFF"; nocase; \
content:"anih"; nocase; \
byte_test:4,>,36,0,relative,little;\
);

This signature first triggers on the pattern "RIFF" for the Microsoft generic multi-media file format. It then triggers on the pattern "anih" for the vulnerable subsection. It then extracts a 4-byte length field, relative 0 bytes from the end of the "anih" pattern, and triggers when that length is greater than 36.

This is how things are done in the intrusion-detection industry, yet when you take a class on intrusion-detection, they claim it ISN'T done this way. Instead of vuln-analysis and vuln-sigs, they teach you that intrusion-detection is done by analyzing the exploit, looking for patterns unique to that exploit.

Since most intrusion-detection products had 0day detection for this bug it stands to reason that intrusion-detection SERVICE PROVIDERS should also have had detection. YOU SHOULD ASK THEM. I'm sure if you read the marketing literature of product and service providers, everything is wonderful, but if you force them to prove to you that they were detecting this problem, things might not be so rosy. The service provider might have been using a poor intrusion-detection system. The signature might have had too many false-positives so was disabled. Or somebody was stupid and just didn't turn on the signature. I would love to see every managed intrusion-detection provider publish a graph of the detection of this bug over the last 6-months. (Indeed, I'm a bit annoyed right now since I no longer work for Internet Security Systems, and I can't just ask the service-provider folks to execute a database query for me).

The reason I suggest talking to service providers is that while most intrusion-detections systems based their signatures on vulnerabilities, there is still a big difference in the quality of the signatures. For example, the above Snort signature is prone to false positives. Any file containing both "RIFF" and "anih" will likely trigger the bug. While this is rare for any particular sensor, this is a high enough rate of false-positives that a large service-provider might turn off the signature.

The above signature only works on a small number of ports assigned to HTTP. In reality, hostile servers are delivering this attack on virtually any port. Another problem is that Snort is typically configured to only analyze the first few hundred bytes of an HTTP response, which means it will miss the attack unless it's the first filed deliver in a response.

The above signature example only covers HTTP, but it can come across other transports, such as instant messengers or e-mail. As far as I can tell, no Snort signatures have been written for these other transports. Indeed, it was announced that e-mail spam was a major vector for this attack.

I point these flaws out because people treat intrusion-detection like magic. They don't understand the signatures they download and put in their intrusion-detection systems, but instead treat them as magical incantations. After every major event, I see signatures posted to various websites, but they are usually incomplete. That's why you pay more for commercial products: they invest more in detection. For example, Proventia (the product I worked on) solves the above problems because it has a full protocol-stack; indeed, many customers are using it right now to block high rates of ANI exploit spam. However, since most people treat signatures as magic, there is little discussion about what's really going on with the signature. It's not hard creating better signatures, it's just that since so few classes teach how signatures are actually developed, and so few users actually read the signatures, that there is no pressure to create better ones.

Tuesday, February 13, 2007

Update on Solaris telnet issuse.

http://blogs.sun.com/tpenta/entry/the_in_telnetd_vulnerability_exploit

It seems there is a patch available pretty quickly. This does not mean you should turn telnet back on though, leave it off.

Big round of applause for Sun owning up to the mistake and fixing it quickly.

Sunday, February 11, 2007

Trivial remote Solaris 0day, disable telnet now.

NOTE: Following link may not we work safe due to cartoon...
http://www.com-winner.com/0day_was_the_case_that_they_gave_me.pdf

Oh jeez, that’s not good. This was posted to Full-Disclosure. Remote root exploit in the Solaris 10/11 telnet daemon. It doesn’t require any skill, any exploit knowledge, and can be scripted for mass attacks. Basically if you pass a “-fusername” as an argument to the –l option you get full access to the OS as the user specified. In my example I do it as bin but it worked for regular users, just not for root. This combined with a reliable local privilege escalation exploit would be devastating. Expect mass scanning and possibly the widespread exploitation of this vulnerability.

And example of the command line is

telnet -l "-fbin" target_address

Please disable telnet on Solaris at this time. The HEV for this will be shipping to ErrataSec customers within the hour.



UPDATE: There seems to be some conflicting reports about this vulnerability working with the root account. This does not work on a default install of Solaris 10. By default a variable is set in /etc/default/login called CONSOLE. If this variable is set then root is not allowed to login from anywhere but the console. Commenting this variable out allows root to login from anywhere and allows this vulnerability to take advantage of the telnet exploit. Below is a pic of my trying it with console set then with console commented out.

Wednesday, January 31, 2007

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?