Its V-A day....

In a few hours I’ll be taking the stage at Blackhat DC to give a Device Drivers 2.0 talk. This is an updated version of the material from Blackhat Vegas as well as new information about how to find and exploit wireless device driver vulnerabilities. The last 20 minutes of the presentation are devoted to Apple. Since I am no longer gagged I will finally, publicly refute the statements Apple made concerning never sharing anything with them. I will go through the timeline of what was shared, when, and what vulnerability it will point to. I am unfortunately unable to present any material sent to my email address at my former employer, but what I can share definitely destroys the claims that Jon and I were irresponsible, frauds, and shared nothing with Apple.

Bluetooth vuln...Nobody said anything about a Bluetooth vuln...

UPDATE: It was just mentioined to me how funny it is that the book I co-wrote about this here tells you how to findthese vulns. I guess my pundits didn't feel the drive to try it...

Blogging Blackhat

The big story today is how a company (HID Corp) successfully suppressed a talk by threatening to sue a researcher (Chris Paget). This is the third such action in recent times, after Cisco tried to suppress Mike Lynn and Apple tried to suppress Dave Maynor. The threatened legal action in this case is that HID claims Paget's work infringes their patents.

There is an important legal distinction here. In the Lynn case, Cisco claimed it was about trade secrets. In trade secret cases like this, a company is forced to take legal actions against their will. They cannot selectively enforce their rights against some people but not others, they must sue people even if they don't want to, else people would be compromise their trade secrets and claim that since Cisco doesn't sue in some cases, they cannot sue in any case.

The same is true of trademark infringement. When Steve Jobs announced the iPhone, Cisco was forced to immediately sue Apple over the trademark. Cisco didn't have a choice in the matter: even though they wanted to negotiate in a friendly manner with Apple, they had to immediately file court papers against Apple. Otherwise, they would lose any rights they had over the trademark.

While you cannot selectively enforce secrets and trademarks, you can be selective about patents. In other words, you can choose not to sue some people who infringe your patents, and choose to sue others. Just because you failed to sue person A does not hurt your suit against person B.

Thus, Cisco's reason is at least plausible, but HID's reason is not. They are not actually suing to protect their patents, they are threatening to sue in order to suppress free speech.

However, it's not likely to suppress much. You can get schematics for a device that can be used to break into HIDs systems here http://cq.cx/proxmark3.pl, you'll just have to do a few hours of extra work without Plaget's speech.

The Norwich Witch Trial

Most have probably heard of the teacher convicted of "harming minors" because she couldn't figure out how to stop the constant porn popups on the classroom computer. Many are outraged because of what they see as an injustice caused by the court's inability to understand basic computer concepts (in much the same way witches were tried and convicted in Salem, MA, in the 1600s).

The recently published transcripts (http://tinyurl.com/34rxbr) paint a different picture. The person most to blame is the defense's "expert witness", Mr. Horner. While he understood the technical content, he understood nothing about the law. In other words, the computer people shouldn't be mocking the stupidity of lawyers, lawyers should be mocking the stupidity of computer people. I'm frankly astonished by Horner's lack of understanding of basic courtroom concepts. Take this exchange, for example:

....
Q: (a question)
A: (an answer)... to the best of my knowledge.
Q: Why do you qualify your answer to the jury?
A: Because you're talking about two years ago.
Q: So you don't know?
A: I'm pretty sure.
Q: Pretty sure, but you don't know, correct? You don't know for sure.
A: Correct.
...

When you are an "expert witness", it's your job to know your subject matter. You can be "pretty sure" about the weather, but you are supposed to be "absolutely sure" about computers. Otherwise, you are not an expert.

He fell into the same trap that all computer geeks fall into: trying to explain things, especially during cross-examination. Under cross-examination by the opponent, your job is give the minimum information necessary to answer the question. You aren't supposed to obstruct his examination, but you aren't there to help him, either. For example, if they ask "did you have a job in college", a bad answer is "yes, at McDonalds for six months". A good answer is just "yes". If the opposing lawyer wants to know where and when, he'll ask.

At one point, Horner answered "I don't know where you are going with that question". You aren't supposed to care where they are going. You are not there to plan ahead an outwit them., you are there to truthfully answer his questions. Most of the time, they really aren't going anywhere: they are just waiting for you to say too much then pounce upon it. (In contrast to Horner, the prosecution's wittnesses seemed to have been taught this basic concept).

Horner was there to show that the technical analysis proves the popups came from innocently surfing a hairstyle site, and not willfully accessed by the teacher. It was his incompetence (and possibly his lawyer's) that made him unable to prove this.

However, even that may not have mattered. She was found guilty of "willfully causing or permitting the victims to be placed in a situation that was likely to impair their morals". While we debate whether she intentionally "caused" the situation, it's certain that she "permitted" the situation to continue. She didn't turn off the computer, cover it up, or remove the kids from the classroom.

Of course, the people we get to most laugh at are the people of Norwich, Connecticut, who think that such popups harm their kids, and that their kids haven't already seen them anyway. People: the Internet has already corrupted your kid's morals, get used to it.

Needs more cowbell

With a few utils from here, and a ruby package from a friend of mine, its pretty easy to get metasploit running on a Nokia N800. I love that cow banner.

Thanks go out to HD Moore for making metasploit so easy to install on new platforms.

UPDATE: Breaking into a Win2k SP4 server using the ms03_026_dcom exploit. This is nifty!

Network Coding, Part 2

[ Part 1 ]

A vuln was discovered in Snort's DCE-RPC reassembly, similar to last year's bug in their SunRPC reassembly. These problems stem from Snort's core architecture. There are two ways of constructing a network applications like intrusion-detection, streaming and backtracking. Snort uses the backtracking model, which is more prone to such mistakes than the streaming model.

In a streaming system, once a byte of input is analyzed, it will no longer be re-analyzed. In a backtracking system like Snort, the technology may go back and re-analyze previous bytes, requiring more complicated reassembly architecture to store those bytes. Streaming models are inherently faster, more reliable, and more secure - but much harder to program.

An intrusion-detection system has a choice whether to use backtracking or streaming technologies. The well-known pattern matching algorithm Boyer-Moore works by skipping ahead, then backtracking, and would be inappropriate for a streaming system. On the other hand, the Aho-Corasick searches for patterns one byte a time, and would work well in a streaming system.

The same applies to more complex pattern-matching using regular-expressions (regex). A regex represents a finite automata. There are two basic ways that a finite automata might work. Using an NFA, all possible combinations of the regex are tested at runtime using backtracking. Using a DFA, all possible combinations are put into a big table, and each streaming byte of input causes a transition to a new state in the table.

Both a backtracking and streaming IDS needs to take care when writing regex expressions to avoid an explosion of possible states. When compiled as an NFA, a hacker can attack the system by causing all states to be traversed. A recent paper shows that a backtracking system like Snort can be DoSed with as little as 4-kbps by causing all backtracking states to be traversed. When compiled as a DFA, the explosion of states will cause all memory to be consumed when compiling the regex - what looks like a simple regex can, in fact, require a DFA of 5-gigabytes to store all combinations.

The streaming model can be used for protocol-analysis as well as pattern-matching. There are not many examples in the open-source community, but a good one can be found in Mozilla's GIF parser (function gif_write() in GIF2.cpp). This code parses the GIF format one byte at a time as the image is streamed from the web-server so that it can render it in on the screen before the file has been completed downloaded. Since each byte is processed individually, each incoming fragment of data is processed by itself rather than being reassembled.

The Mozilla GIF parser looks almost identical to the GIF parser I wrote for the Proventia IDS/IPS. Its structure is similar to all the other 200-odd protocol decodes in Proventia, including the SMB and DCE-RPC parsers. These parsers decode the protocols as a stream of bytes.

Since all the logic in Proventia is stream oriented, it does not actually "reassemble" fragments, it just "reorders" them. When one fragment ends and the other starts, it continues where it left off as if there were no fragment break. The TCP protocol delivers a series of ordered fragments to the NetBIOS/SMB decode, which itself delivers a series of ordered fragments to the DCE-RPC decode, which delivers a series of ordered fragments to the application decodes on top of DCE-RPC. The simplicity of this approach is why Proventia has had SMB and DCE-RPC "reassembly" in the core engine as far back as 2000, even though the major DCE-RPC vulnerabilities weren't discovered until 2003 (in contrast, Snort added DCE-RPC reassembly in 2006).

I talked about ASICs in Part 1 of this series. As Chief Scientist of ISS, I had ASIC vendors come to me with proposals to accelerate TCP reassembly and regex pattern-matching. Not only were their proposals slower than our shipping products, but they had a hard time grasping the concepts that (a) TCP reassembly isn't really needed, and (b) their methods of accelerating regex by converting to a DFA can be done in software without their ASIC.

I have talked to engineers at Ironport (an e-mail appliance) and Sidewinder (a firewall). They have indicated that they use the same approach in their products. Like Proventia, they are the fastest in their class of products. Even Microsoft's IIS uses a streaming model. For example, when sending a "GET /index.html HTTP/1.0", you can send 5-billion spaces between the "GET" and the "/index.html". This is because Microsoft is using a state-machine to parse the incoming bytes from TCP. In contrast, Apache reads in a block of 16k bytes, then backtracks to re-parse the boundary between "GET" and "/index.html".

Snort Remote RPC 0day

http://www.snort.org/docs/advisory-2007-02-19.html

Snort announced a vulnerability today in their SMB and DCE parser. Basically while reassembling some SMB traffic there was no bounds checking and a simple stack overflow was possible.

From the changelog:

2007-02-16 Steven Sturges
* src/dynamic-preprocessors/Makefile.am:
* src/dynamic-preprocessors/dcerpc/smb_andx_decode.c:
* src/dynamic-preprocessors/dcerpc/dcerpc.c:
Add bounds checking to ReassembleSMBWriteX; use Safememcpy for calculated
length buffer copies.

Congrats to exploit ninja and my personal hero, Neel Mehta, for finding this.

Exploit and HEV should be available for customers in a few hours.

Errata loves ebay

Anybdoy wanna guess what these are for? If you said reversing Cisco routers for exploit and vulnerability dev you would be right. Because Cisco refuses to share vuln information with anybody, Errata is one of the few companies you can go to for details on cisco flaws.

High-performance security appliances

See [ Part 2 ] of this series.

I was reading this blog post about ASICs. ASICs are like herbs. While scientists cannot find any benefits to having herbs in shampoo, the public widely believes they make a difference. Therefore, it's impossible to find shampoo that doesn't have herbs in it.

There are lots of firewalls, e-mail appliances, and intrusion-prevention products that don't have herbs^H^H^H^H ASICs, which yet manage to have good performance. For example, the my (former) Proventia product could handle 5-gbps of real-word traffic with 30-microseconds of latency. And it does this without taking shortcuts. When you look under the hood of ASIC-based systems, you'll find that it's not the ASIC that made them fast, but some sort of sacrifice they've made (such as not analyzing HTTP responses).

To make code run as fast as ASICs, we have to use special techniques. For example, imagine writing a high-performance DNS server. When packets arrive in a buffer, they reset the cache flags. Reading the first bytes of the packet will cause a cache-miss, which causes the processor to halt for 300-cycles. Likewise, when resolving a random name, the name is unlikely to be in the cache, which is another 300-cycle hit. On a multi-processor system, threading locks require hard bus transactions, which can be as much as a 600-cycle hit.

When trying to process 3-million requests per second on a 3-GHz x86 processor, you have only 1000-cycles. The above requirements would seem to indicate that you need a minimum 1200-cycles, but you can use tricks to get past this. When processing an incoming request, you can execute a cache-prefetch instruction on the next packet. Thus, that packet will already be in the cache by the time you get to it, thus avoiding cache misses when you start processing packets. Likewise, when you get to the DNS name, instead of reading the table entry, you can execute a prefetch on it, then continue processing the previous packet. Lastly, instead of using normal synchronization primitives that lock the bus, you can construct the code with producer-consumer queues that don't require bus locking.

Thus, with careful coding, you can get rid of all the processor stalls.

Network ASICs from Cavium, RMI, Consentry, etc. solve the problem of processor stalls a different way. They are aggressively multi-threaded, so that when the processor stalls on one thread, they continue executing a different thread. They will help network applications that have frequent stalls (e.g. Snort), but would have no benefit on code that has engineered around the stalls (e.g. Proventia). At ISS, we jokingly referred to all the "hardware accelerators" as "decelerators".

These chips are useful for power consumption, but even there Intel has almost caught up with the Core 2 Duo, and is likely even to surpass them later this year with their 45nm process with a hafnium dielectric.

A new meaning for Denial-of-Service attack

http://en.wikipedia.org/wiki/Metalstorm

I mean...wow.

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.

Steve Jobs and DRM...

I have been waiting to comment on Steve Jobs call to end DRM enabled music becasue I just don't know what to say. To be honest it’s kind of out of my knowledge scope. I sometimes feel like Dr. McCoy: “damn it Jim, I’m a security researcher not a consumer rights advocate”. My thoughts are that it was a very bold move and even if he has done it for various reasons like some people claim if DRM goes away that means consumers win in the end. I think John Gruber does a better job analyzing it than I ever could.

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?

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.

Lost became lost...

I know our typical beat is information security but I thought I would take a moment to discuss something a little more personal. I have lost interest in…Lost. My love affair with Lost started when a previous girlfriend bought me a video iPod for my birthday. There wasn’t much on iTunes yet in the way of video content so I bought the first season of Lost. I was hooked. After learning about the black smoke, the hatch, people suddenly walking and what not I couldn’t wait for season 3 after watching season 1 and 2 in a few weeks. Season 3 started late then took a long hiatus. This made me mad. I am tired of these network execs suddenly deciding to spread shows out as much as possible to maximize advertising revenue. After returning home from RSA iTunes was waiting for me with the first new episode in a long time. I watched it and the spark was gone. I suddenly didn’t care about the characters anymore; I had gotten over it all. I have had similar feelings for the Sopranos. From now on I think I’ll just wait for the season to be done then download them all.

Quantum redux

A company called D-Wave promises to demonstrate a 16-qubit quantum computer. This is scary.

Using a quantum computer and Shor's Algorithm, we can crack an RSA key of the same size as the number of qbits. Thus, a 2048 bit RSA key can be cracked by a 2048-qubit computer. (It's a little bit more complicated than that, but that's the gist).

There is a probably a "Moore's Law" equivelent for quantum computers. The number of qubits we can hold together is doubling at a rate. We just need to figure out what rate that is. In 2001, IBM demonstrated a 7-qubit computer. This gives a doubling rate of around 4-years, which means we'll start being able to crack the smallest RSA keys in about 20 years, and large 2048 RSA keys in 30 years.

Each new advancement in quantum computer gives us another data point to figure out the "Moore's Coefficient" for the industry, which narrows down how long it will take before today's crypto becomes absolete. If it turns out to be 2 years, then in 15 years today's crypto becomes obsolete. If it turns out to be 1 year, then in 7 years it's obsolete. I just keeping your packet sniffer captures of VPN and SSL traffic on DVDs until then -- there is a good chance you'll be able to decrypt them in a few years.

Blogging RSA

I was standing next to a booth, and a sales person was explaining the word "exploit" to an executive.

There needs to be a sign out front of the sort "You Need To Be This High To Go On This Ride". You need to know the words like "exploit" mean. Otherwise, every product is advertising the most comprehensive, proactive solution with the greatest Return On Investment. If you don't know the actual deferentiators, then you'll buy according to who has the slickest market message, the hotest booth babes, or the best golf scores.

It's easy to blame the vendors for their vapid marketing, but we should blame the buyers who evaluate products without knowing how they work.

Root DNS attacked, that's sooooo 20th century

According to an AP article, some of the 13 root named servers were overloaded recently. Overloading the root servers has long been one of the Top 10 Techniques for DoSing the Internet. It wouldn't actually stop packets from being routed, but trying to resolve www.praetorian.com to IP addresses like 24.75.345.200 would no longer work, and your browser wouldn't be able to get to websites.

However, the root system has been hardened against such attacks, especially after an incident in 2002.

One defense implemented by servers has been to split the workload. In the past, the root name servers would resolve the last 2 portions (like "example.com") and leave the rest for your ISP to continue resolving. Now they just resolve the last portion (like ".com"). Other root-like servers do the second level resolution. For the attacker, this means there are a lot more servers they need to attack.

Another defense, used first by the 'F' root server, is 'anycasting'. It's IP address of 192.5.5.241 does not route to a single machine, but instead to one of roughly 40 machines spread throughout the Internet. If you were to flood it from a single machine, you could only take out one of them. You would need at least 40 separate sources to flood all 40 machines.

Yet another defense are ISPs that cache results. This leads to its own problems, such as return stale data, but this means that if the root system failed, they would still be able to return good enough results.

As a result of all these defenses, it's unlikely that DoSing the root servers would be viable attack. A better offense would be to find a DoS in popular software such as BIND or Microsoft DNS, catalogue all the servers that use it, then DoS them all at once.

One thing that I've always found curious was that the root servers don't use custom software, but instead off-the-shelf platforms like Solaris and BIND. We created the Proventia IPS using custom network drivers, custom TCP/IP stacks, and custom protocol parsers. Using similar techniques, we could create a system for serving 10 times the requests that such systems can currently handle.

Warning...Long post on how OSX does not has ASLR.

One of the posters to my “Bill Gates fights back” posted a very intresting statement that I felt deserved an entire blog entry for.

“First off, check the address spaces of the same framework on two different computers crash logs on OS X. Not identical.”

Ok. Because of my job I just happen to have a DoS and a weaponizied version of MoAB #1 lying around. Since popping a shell won’t get me the crash logs I need, we have got to use the DoS. I wrote the exploit based on HDM’s WMF module, its pretty nifty.

msf exploit(MOAB-01-Quicktime_rtsp) > exploit
[*] Started bind handler
[*] Using URL: http://192.168.1.108:8080/X34OVYSZq7nAQf5
[*] Server started.
[*] Exploit running as background job.
msf exploit(MOAB-01-Quicktime_rtsp) >

So going to the URL http://192.168.1.108:8080/X34OVYSZq7nAQf5 will get a crash. I do this on my desktop machine (a mac mini) and my test machine (also a mac mini). And I get a crash on each.
So I diff the two.
$ diff testmacmini.log desktop.crash.log
3,4c3,4
<> Host Name: david-maynors-computer-2
> Date/Time: 2007-02-05 08:55:15.473 -0500
10c10
<> Parent: WindowServer [62]
17c17
<> PID: 191
50,53d49
<> Thread 4:
> 0 libSystem.B.dylib 0x9001aafc select + 12
> 1 libSystem.B.dylib 0x90024b07 _pthread_body + 84
>
75,80c75,80
<> 0x5ae000 - 0x5affff com.apple.textencoding.unicode 2.1 /System/Library/TextEncodings/Unicode Encodings.bundle/Contents/MacOS/Unicode Encodings
> 0x14bc5000 - 0x14bd3fff com.apple.quicktime.webplugin 7.0.4 /Library/Internet Plug-Ins/QuickTime Plugin.webplugin/Contents/MacOS/QuickTime Plugin
> 0x15092000 - 0x150aefff GLDriver /System/Library/Frameworks/OpenGL.framework/Versions/A/Resources/GLDriver.bundle/GLDriver
> 0x150b5000 - 0x150d6fff GLRendererFloat /System/Library/Frameworks/OpenGL.framework/Versions/A/Resources/GLRendererFloat.bundle/GLRendererFloat
> 0x15169000 - 0x152aafff GLEngine /System/Library/Frameworks/OpenGL.framework/Resources/GLEngine.bundle/GLEngine
> 0x152d2000 - 0x15327fff com.apple.driver.AppleIntelGMA950GLDriver 1.4.32 (4.3.2) /System/Library/Extensions/AppleIntelGMA950GLDriver.bundle/Contents/MacOS/AppleIntelGMA950GLDriver

Yes indeed there are some differences. This does not mean ASLR has been implemented. In order to take advantage of this vulnerability you need the address of System() to stay static. That is contained in the libSystem library which stays static across machines.

0x90000000 - 0x9016efff libSystem.B.dylib /usr/lib/libSystem.B.dylib

The address of the System() function is at 0x90046c30 on both machines. The libraries containing this never change location, only some of the framework stuff. The fact some of the framework addresses load at different addresses does not provide you with any security benefit.

If you want to see the full crash logs email me and I am happy to send them over.

Gruber is upset about a Gates quote, not about the lack of security technology in OSX

http://daringfireball.net/linked/2007/february#sun-04-maynor

Mr. Gruber,
Thats what you are upset about?!?! You cover a company that is notorious for PR spin and you are upset about Bill Gates making a comment? Bill Gates made a comment, he didn’t run a marketing campaign based around something absurd like “we don’t have security problems”. So following this logic you must be highly upset with Steve Jobs for daring hackers to find holes in OSX with that marketing campaign. I firmly believe that 2006 was one of the worst years for Apple security because of those ads and 2007 isn’t looking much better.

You are not mad that Microsoft's latest Operating Systems out classes OSX hands down in the areas of security and anti-exploitation technology but instead one comment Bill Gates made to a reporter? Tell you what, when Microsoft starts running commercials that feature the Month of Apple Bugs then you have every right to complain. How about until then you demand Apple tell you when similar security features will be added to OSX that are now shipping in Vista. Also please note I didn’t even bother commenting on things like UI design because its not really my area of knowledge so I refrain from offering my opinion on it.

I really think your anger is misplaced.

BitTorrent curiousities

I've been playing around with BitTorrent again lately. One of the things that been nagging me is where "failed hashes" come from.

BitTorrent transfers files in smaller pieces, usually around 256kbytes, and double-checks them with their own hash (.torrent files are so big because they contain a list of all the hashes for all the pieces). Sometimes when you download a piece from a source, it fails the hash check, meaning it was corrupted.

One reason that's been documented on the web is that sometimes Internet devices have bugs that corrupt data. D-Link has a "gaming" mode that tries to fix some gaming protocols by correcting your NATted IP address. This means, in 4-billion bytes of random/compressed data, it will mistakenly see what it thinks is an IP address is needs to correct, thereby corrupting the chunk.

Another source of corruption is TCP. Its checksum doesn't always catch multi-bit errors. Therefore, it will report a packet as good that is actually corrupted.

Finally, one source I've found is that large chunks of a piece can be corrupted. I'm guessing that the file system on the disk drive of the sender got corrupted.

This points to two obvious changes that would be good for BitTorrent clients. The first is that senders should re-verify pieces when they send them (not just on reception) to see if they've been corrupted on the disk in the meantime. Second, clients can easily save the bad chunks and figure out why they got corrupted.

For example, a client could compare the bad chunk with the eventual re-download of a good chunk. It could run tests on the regions of the pieces that differ. The nice thing about the TCP checksum algorithm is that you can just run it over those regions: if the corrupted piece and good piece have the same TCP checksum, then it's a good chance that the reason the chunk was corrupted was because of a network problem.

Likewise, if an entire 4k portion was corrupted, it's likely a disk error. If a 4-byte part is different, then it's likely the D-Link bug.

More on the Apple wifi blunder OR i am no longer gagged

In response to a question on the security focus apple list I decided to reply. Gotta love the lack of gag.

I wrote this (with some edits):

Jon and I didn't discover a serious general 802.11 flaw, that's is where alot of confusion around this issue comes from. We discoveredthat in general 802.11 drivers didn't handle malformed frames very well. The flaws that were discovered (there were far more than one) were specific to certain types of chipsets (atheros, broadcom, etc...). As far as the articles go I didn't write them. If you look at mine and Jon's quotes in each article you will see something along the lines of"this is a systemic problem that affects the entire industry". I am also amused by the fact I wrote about how to find these vulns in a securityfocus article and nobody but HD Moore seemed to care. He added the ability to audit wireless drivers to metasploit. Which is really cool.

As far as when we used a third party card for the video demo. Alot of Mac fans were very upset and felt that it wasn't fair because nobody uses a third party card. That was the entire point of the demo. If we had to do it live and someone got a copy of the working exploit we didn't want it to be in something that actually affected anyone. As far as confirmation you will see we never confirmed publicly which vendors were affected. And once again I never said I wanted to stab the mac community in the eye, I said that about the actors in a commerical.

As a side note I have to mention the statement that Secureworks issued clarifying the video. She (being Lynn Fox) forgot to mention to reporters that statement was created in cooperation between Apple PR and Secureworks PR. Although Apple PR really wanted the statement to be extended to cover any demos given in person (Krebs, anonymous Blackhat employee)Secureworks couldn't do that. Minutes after this was posted Lynn Fox started pitching reporters a story that Secureworks had changed its tune based on the update. If you actually read the Secureworks statement it just covers the video and says nothing I didn't say in the video twice. I suppose her omission of this information was designed to make it appear Jon and I were frauds and thus make a big story. I suppose the headlines "Apple asked Secureworks to clarify their video, Secureworks obliges" would not have been as sensational or given the Mac zealots ammunition to drag Jon and I through the mud for months. She then called my boss at Secureworks at the time and told him she was very sorry the Mac community was taking what she said out of context, and she never intended that to happen. I also find it funny the only real news outlet that ran the Secureworks changes position story was Macword. Here is a funny note, the guy who wrote the story, Jim Dalrymple never contacted Jon,myself, or Secureworks for any reason during the entire fiasco.

It doesn't matter much to me anymore as I have yet to meet a client of Errata Security (the company i formed after leaving Secureworks) that thinks I faked it all, in fact pretty much everyone i meet thinks Apple tried a cover up that blew up into a long drawn out affair, also most Enterprise customers don't care about Apple. Also I am in the process of writing a book about horror stories of when responsible disclosure goes wrong with Apple being the flagship issues. Everything that happened will be detailed. As far as security research into Apple I haven't done much else in the last few months and I flat out refuse to report any issues to Apple security anymore because of two things. One is that i don't trust their PR department not to try and smear me again, i feel that their handling of the Secureworks statement (which again was done at their request) pretty much proved this. The second reason is simple: Apple apparently has more leaks than a sinking ship. How do I know this? Several of the bloggers who were calling for my head on a platter had information I had given to just one person at Apple and that no-one else knew, not even Jon. Its almost like pro-mac bloggers have a hotline to the 2 or 4 person security group at Apple. If a company wants me to keep details of a vulnerability private, they can at least do the same.

So what is the take away from this? It was a very poorly handled situation by everyone involved, except Jon. Jon had no real control of any of this and in the end I realized I didn't either. I lost all control when I allowed marketing people to make decisions about vulnerability disclosure. However I did make some mistakes. I should have never talked to a reporter about something we were not ready to make public. I should have realized Apple would have responded the way they did and just dropped full details of the exploit or not said anything at all. The PR war Lynn Fox waged against me was only possible because she knew i was forbidden from defending myself. With that being said I have never been a fan of full disclosure, and I am still not, unless its a vendor that has acted in bad faith. How could it have been handled differently by Apple? I have reported alot of vulnerabilities to alot of vendors and never once have I had the PR department respond to something. Take the Dell and Toshiba Bluetooth stack issues. We reported it to security, we worked with the engineers to fix it (and strangely information we gave to the engineers didn't end up on blogs), and only after everything was fixed(the process took about a month and a half) did we talk to their PR group to coordinate a joint release.

With all this being said I am shopping for a new TV to make best use of my new Apple TV when it arrives. I write this on a new Macbook Core Duo 2 while listening to my ipod play an audiobook (World War Z) that I bought from iTunes. If you didn't know better you could also say I am a walking commercial for Apple.

Is this over? Far from it.

More on Apple security Vs. Microsoft Security

Some people feel that my last post means that that Vista is perfect from a security standpoint and will not have any hacker problems. Please re-read the post. I said is that Microsoft has worked hard to eradicate most of the current, popular exploitation methods. This doesn’t mean its hacker proof. Why? Because people will develop new methods. That what security researchers will do. Unfortunately for researchers Microsoft has hired a ton of talented security people that are also trying to come up with new methods so they can plug them before anyone knows about them. To my knowledge not many other vendors, including Apple, are doing anything like this.

What does this mean? In the end not much, every vendor is still locked in the same arms race with hackers they always were.

Bill Gates fights back against an evil corp?!?!

UPDATE: For a response to John Gruber check here. For more discussion on the lack of security features in OSX, check here.

http://apple.slashdot.org/apple/07/02/02/1940232.shtml

The Mac community is up in arms. Bill Gates gave an interview where his fights back against some Apple’s misleading and deceptive marketing.

As a side note those commercials are what lead me to do security research in Apple. Also the quote that is quite often attributed to me about “cigarettes in mac users eyes” is a misquote as I actually said “cigarettes in the eyes of the actors in the commercials”. But I digress.

"Nowadays, security guys break the Mac every single day. Every single day, they come out with a total exploit, your machine can be taken over totally. I dare anybody to do that once a month on the Windows machine."

Oh the Mac fans are upset. *rabble*rabble*.

http://www.limited-exposure.org/2007/02/02/hey-bill-keep-up-will-ya/

http://www.securityfocus.com/archive/142/458920/30/0/threaded

http://daringfireball.net/2007/02/lies_damned_lies_and_bill_gates

The limited exposure guy even went as far as to count the MoBB bugs to prove how insecure Windows is. He forgot to mention how many of the affect Windows Vista and IE7 (HINT: not 25, that’s for sure).

Take a seat, hold your hats because I am about to make a declaration: Windows Vista is more secure than OSX 10.4.8. Anybody that tells you anything different should immediately be treated with the same disdain as finding a parking ticket on your car. This hasn’t been a popular thing to say and it’s not often said, but I am here to stand my ground on this. It sure won’t win me any karma on Slashdot.

Why do I think this? One new exploitation methods have to be developed to take advantage of a Vista vulnerability. Let’s look at why:

Stack overflows are gone. Don’t think this is just because of NX, or Non-eXecutable stacks. NX just means I can’t execute code on the stack but return-to-libc attacks still work. With things like ASLR (which is implemented on Vista and not OSX) breaks return-to-libc attacks because the system libraries are loaded at different, random addresses every time. Count how many of the Month of Apple Bug exploits were stack overflows. The most dangerous one, MoAB #1, was.

Heap Overflows are pretty broken is not eradicated. With heap randomization, metadata elements and function pointers being XORed with random numbers it would be next to impossible to exploit a heap overflow on Vista in the traditional way. OSX doesn’t have any similar protection.

Tom Ptacek even comments on the lack of advanced security features in OSX here.

What does this mean? In order for attacks to continue in the same way there will have to be some MAJOR evolutions in vulnerability and exploit technology as almost all of the widespread flaws you have heard of take advantage of these methods. Blaster, Sasser, Slammer, Zotob, all those big worms have relied on either a stack or heap based overflow.

Don’t believe me? Prove me wrong. Now don’t get me wrong, you can still email executables to people and then trick them into running it…you can do that on OSX as well.

Of course this won’t do anything to calm the swell of zealots or people stuck in the belief that Microsoft hasn’t changed since 1998. Its kinda like when explaining, in-depth, a black Ferrari is a better car than a red Honda civic to a teenage girl. The same logic that would lead the teenage girl to say “but I like this one better because its red and goes with my lipstick” is the same logic a Mac zealot will use when they say “I don’t care about the facts, I KNOW OSX is more secure”. Know I can’t comment on usability or any of that jazz, that’s not my area of expertise. I’ve never had a problem setting up and running either.

The thing that really upsets me about the Mac community going off on Bill Gates is that Apple does the same exact thing. Their "we don't have security problems" commericals are the same thing as what Bill Gates said. If you want to be mad at Bill then hold Steve accountable for the same actions as well. The arrogant commericals Apple runs has done nothing but win them alot of researchers who are breaking their systems that would not have otherwise given them a second look.

I’ll leave you with my favorite Mark Twain quote:

“It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so.”

UPDATE: Please understand that I'm not referring to the average Mac user that just wants a safe, reliable computing experience. I'm taking exception with zealots who place those users at risk by giving them a false sense of security. OS X is pretty safe today for the average user, but the platform is definitely NOT as fundamentally secure as Vista. Microsoft only changed when users demanded better security, and it's only when the Mac community calls for similar protections that Apple will include them in products. I use my macbook on a daily basis. I write code on it, I watch movies on it, I chat with people on it. Just becasue I don't think highly of the security in OSX doesn't mean I am not a Mac user.

Tennis balls and car locks...

The Hole - video powered by Metacafe

Bad security isn't just in the IT industry. I am planning on trying this on my car.

Blogging on our own blog

I probably should just do a normal "comment" on Dave's entry before, but I thought it's worth it's own ErrataSec blog entry.

DON'T affix a sticker saying "NOT A BOMB" on devices you take through airport security. It's against the rules, you will get into trouble. (...and no, that's not a silly rule, there are good reasons why it's bad).

Soon after 9/11, ISS had this marketing campaign and gave out T-shirts that said on the front "a different kind of THREAT", and on the back "needs a different kind of SOLUTION". The word THREAT was huge across the front.

So of course, I had to see if I would get into trouble, and wore it to the airport on my next business trip. I wore it on every business trip for the next year. I didn't get into trouble, but the TSA people would usually make a comment about it (not a comment saying I shouldn't wear it, more of a comment reflecting the fact that they noticed it).

Take it from a man that lived in Boston...

http://www.bunniestudios.com/wordpress/wp-trackback.php?p=153

I think these should be affixed to all new projects to prevent confusion.

George Ou's hack gets a marketing name...

http://www.infoworld.com/article/07/02/01/HNvistaspeechbug_1.html

SHOUT HACKING!!!

I know, I know it seems like the kinda name a trendy techno club with a line of pretty people waiting outside would have. Give it a chance, say it a few times, SHOUT HACKING! Or better yet George Ou presents SHOUT HACKING! (it must be in all caps)

I am taking a bullhorn to RSA, who is with me?

Sales Guy:"Today I will be demoing a brand new product to stop.."
From the crowd: "START LISTENING"
Sales Guy:"all forms of 0day attacks..."
From the crowd: "START"
Sales Guy:"There is not an attack that can get around this..."
From crowd: "SHUTDOWN"

The demo machine shuts down

Sales Guy: "Uuuhh...The battery must have died..."