3 ms·

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 a

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).

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).