4 ms·

Any insights into how researchers find these bugs? I'm particularly interested in the kernel timing bug - how did the researcher know that he would find the kin

Any insights into how researchers find these bugs? I'm particularly interested in the kernel timing bug - how did the researcher know that he would find the kind of exploit he needed? It seems like he's a fast learner, going from no native client code to a big exploit...

diminoten 12y ago
> Using an out-of-bounds read/write vulnerability he claims he found through static analysis, ilxu1a’s attack led to medium-integrity code execution in what ZDI called “sub-seconds,” earning $15,000. Looks like some code analysis tools helped for one researcher.
drinchev 12y ago
I've seen a couple of hackers back in the old days. Of course they've probably moved to some more sophisticated techniques, but I doubt they are wearing suits and doing this as a professionals. More concrete answers of your questions guessing : 1. By brute forcing with popular techniques for buffers overflows ; 2. By tracking what the browser is doing via debuggers and trying to match a kernel bug with it ; 3. By reading a lot about latest exploits on the internet and connecting the dots. What I think nobody from them is doing : 1. Analysing open-source code ( basically try to find the exploit by reading the code ) ; 2. Studying 5 years CS before doing this
- mccr8 12y ago
  People certainly do find security vulnerabilities by reading source code.
  - trequartista 12y ago
    IIRC the Google researcher discovered the Heartbleed bug when he was auditing the OpenSSL code
    - ScottBurson 12y ago
      The Codenomicon team found it using a fuzzer. My recollection is that the Google researcher also used a fuzzer, but I can't find any evidence of that in a brief search.
  - snowwrestler 12y ago
    The nasty Drupal bug from last October was discovered when a (name withheld) company in Europe paid for a professional security audit of Drupal's open-source code. Thankfully when they found the bug, they contributed the patch back to the community.
- SCHiM 12y ago
  @GP 4. By using various forms static/dynamic analysis (taint analysis, fault propagation, fault injection). 5. By fuzz-testing the software. Taint analysis is looking at which registers/memory locations you have access to. You inject data into a process and then check where in memory that data shows up, which execution branches are taken, which registers are used with the data, what the stack does, etc. Fault propagation looks at where errors and faults are handled and how they are handled. The idea is to get a good idea of how a process manages errors and then find an error that is not handled (correctly). Fault injection is injecting errors into a process and then watch the fireworks. Think of this as the brute-force approach to fault propagation analysis. Fuzz testing is bombarding the process with semi-valid/semi-random input and watching what happens. There are many tools with this. Example output for browser-fuzzing could look like this: <html>>style="\>>overflow:none"></body><html> Obviously none of today's browsers would be exploited by that, but with mutli-threaded rendering, memory management, javascript reading/writing html and all that stuff going on at the same time it's not surprising that fuzz testing can turn up lots of errors (though not all exploitable).
fintler 12y ago
I found CVE-2010-0539 (Safari remote code execution) by setting up a website that just fuzzed a ton of stuff. It had a meta-refresh setup so the browser would just keep reloading with a new random fuzz payload. I was in my 2nd year of a CS undergrad program, so I would do stuff like this when I was bored. I think much of it is just a bit of luck that you're looking in the right place.
- highschooler 12y ago
  Can I ask what exactly you where watching for with your fuzzer? Where you just waiting for Safari to crash? Then what?
- tracker1 12y ago
  What's funny, is back in the mid-late 90's, I found a lot of bugs in Netscape Navigator simply by running the browser in a more secure OS (Windows NT) vs. Windows 9x... There were a lot of conditions where the browser would crash in NT, but in 9x meant you had an exploit. Many of those were pretty simplistic... fortunately for almost everyone at the time, the browser wasn't a widely used method of exploit, and to my knowledge compromising distributed computer networks via such compromises and ad networks wasn't thought of either. Though by 2002/2003, I had started blocking Flash, Java and Adobe Reader at home when I saw what could be done in the browser.
tptacek 12y ago
People who exploit browser bugs do it as a profession, or as a passionate consuming hobby. They're generally connecting the dots between a series of lesser flaws. They spend weeks and months banking those lesser flaws, and the patterns that create them. Some of them can come from static analyzers, some can come from theorem provers, some are just lucky finds. For awhile, a lot of them came from fuzzers; if you're interested in how that works, strong recommend for Zalewski's blogs on his open-source "american fuzzy lop" fuzzer. Browsers are huge attack surfaces, as complex as operating systems, with different modules of wildly different quality. There are lot of bugs to find. The process makes more sense when you grok how much effort goes into getting privileged RCE from a hardened browser. Nobody can sit down with that code and pull one of them out of thin air on the spot.
- mike_hearn 12y ago
  Why is it called american fuzzy lop?
  - wolf550e 12y ago
    AFL is a breed of pet rabbit that is fuzzy (fluffy). The software is a fuzzer. https://en.wikipedia.org/wiki/American_Fuzzy_Lop https://en.wikipedia.org/wiki/American_Fuzzy_Lop https://en.wikipedia.org/wiki/Fuzz_testing https://en.wikipedia.org/wiki/Fuzz_testing

diminoten 12y ago

> Using an out-of-bounds read/write vulnerability he claims he found through static analysis, ilxu1a’s attack led to medium-integrity code execution in what ZDI called “sub-seconds,” earning $15,000. Looks like some code analysis tools helped for one researcher.

drinchev 12y ago

I've seen a couple of hackers back in the old days. Of course they've probably moved to some more sophisticated techniques, but I doubt they are wearing suits and doing this as a professionals. More concrete answers of your questions guessing : 1. By brute forcing with popular techniques for buffers overflows ; 2. By tracking what the browser is doing via debuggers and trying to match a kernel bug with it ; 3. By reading a lot about latest exploits on the internet and connecting the dots. What I think nobody from them is doing : 1. Analysing open-source code ( basically try to find the exploit by reading the code ) ; 2. Studying 5 years CS before doing this

mccr8 12y ago
People certainly do find security vulnerabilities by reading source code.
- trequartista 12y ago
  IIRC the Google researcher discovered the Heartbleed bug when he was auditing the OpenSSL code
  - ScottBurson 12y ago
    The Codenomicon team found it using a fuzzer. My recollection is that the Google researcher also used a fuzzer, but I can't find any evidence of that in a brief search.
- snowwrestler 12y ago
  The nasty Drupal bug from last October was discovered when a (name withheld) company in Europe paid for a professional security audit of Drupal's open-source code. Thankfully when they found the bug, they contributed the patch back to the community.
SCHiM 12y ago
@GP 4. By using various forms static/dynamic analysis (taint analysis, fault propagation, fault injection). 5. By fuzz-testing the software. Taint analysis is looking at which registers/memory locations you have access to. You inject data into a process and then check where in memory that data shows up, which execution branches are taken, which registers are used with the data, what the stack does, etc. Fault propagation looks at where errors and faults are handled and how they are handled. The idea is to get a good idea of how a process manages errors and then find an error that is not handled (correctly). Fault injection is injecting errors into a process and then watch the fireworks. Think of this as the brute-force approach to fault propagation analysis. Fuzz testing is bombarding the process with semi-valid/semi-random input and watching what happens. There are many tools with this. Example output for browser-fuzzing could look like this: <html>>style="\>>overflow:none"></body><html> Obviously none of today's browsers would be exploited by that, but with mutli-threaded rendering, memory management, javascript reading/writing html and all that stuff going on at the same time it's not surprising that fuzz testing can turn up lots of errors (though not all exploitable).

fintler 12y ago

I found CVE-2010-0539 (Safari remote code execution) by setting up a website that just fuzzed a ton of stuff. It had a meta-refresh setup so the browser would just keep reloading with a new random fuzz payload. I was in my 2nd year of a CS undergrad program, so I would do stuff like this when I was bored. I think much of it is just a bit of luck that you're looking in the right place.

highschooler 12y ago
Can I ask what exactly you where watching for with your fuzzer? Where you just waiting for Safari to crash? Then what?
tracker1 12y ago
What's funny, is back in the mid-late 90's, I found a lot of bugs in Netscape Navigator simply by running the browser in a more secure OS (Windows NT) vs. Windows 9x... There were a lot of conditions where the browser would crash in NT, but in 9x meant you had an exploit. Many of those were pretty simplistic... fortunately for almost everyone at the time, the browser wasn't a widely used method of exploit, and to my knowledge compromising distributed computer networks via such compromises and ad networks wasn't thought of either. Though by 2002/2003, I had started blocking Flash, Java and Adobe Reader at home when I saw what could be done in the browser.

tptacek 12y ago

People who exploit browser bugs do it as a profession, or as a passionate consuming hobby. They're generally connecting the dots between a series of lesser flaws. They spend weeks and months banking those lesser flaws, and the patterns that create them. Some of them can come from static analyzers, some can come from theorem provers, some are just lucky finds. For awhile, a lot of them came from fuzzers; if you're interested in how that works, strong recommend for Zalewski's blogs on his open-source "american fuzzy lop" fuzzer. Browsers are huge attack surfaces, as complex as operating systems, with different modules of wildly different quality. There are lot of bugs to find. The process makes more sense when you grok how much effort goes into getting privileged RCE from a hardened browser. Nobody can sit down with that code and pull one of them out of thin air on the spot.

mike_hearn 12y ago
Why is it called american fuzzy lop?
- wolf550e 12y ago
  AFL is a breed of pet rabbit that is fuzzy (fluffy). The software is a fuzzer. https://en.wikipedia.org/wiki/American_Fuzzy_Lop https://en.wikipedia.org/wiki/American_Fuzzy_Lop https://en.wikipedia.org/wiki/Fuzz_testing https://en.wikipedia.org/wiki/Fuzz_testing