Where do many of these hackers come from? What is their background?
I ask, as wish to know at a high level what tools and code they are using to find and exploit Chrome.
Anatomy of a hack: 6 separate bugs needed to bring down Google browser
11–16 of 16 posts
Re: Anatomy of a hack: 6 separate bugs needed to bring down Google browser
#12Where do many of these hackers come from? What is their background? I ask, as wish to know at a high level what tools and code they are using to find and exploit Chrome.
OllyDbg, SoftIce and other debuggers and disassamblers.
Re: Anatomy of a hack: 6 separate bugs needed to bring down Google browser
#13The scary part was the limitation that hackers weren't allowed to exploit Windows vulnerabilities. When you think of how many unpatched Windows 7 (or older) machines are out there it's no wonder botnets keep growing..
> the limitation that hackers weren't allowed to exploit Windows vulnerabilities
He guessed "some predictable addresses allocated by Windows" though. Not detracting from the achievement, but this could arguably be stashed in the non-Chrome side of things.
Re: Anatomy of a hack: 6 separate bugs needed to bring down Google browser
#14The scary part was the limitation that hackers weren't allowed to exploit Windows vulnerabilities. When you think of how many unpatched Windows 7 (or older) machines are out there it's no wonder botnets keep growing..
> the limitation that hackers weren't allowed to exploit Windows vulnerabilities He guessed "some predictable addresses allocated by Windows" though. Not detracting from the achievement, but this could arguably be stashed in the non-Chrome side of things.
It's normal, and necessary, for the operating system to provide access to standard library functions; the easiest way to do this is having them at well-known addresses. Admittedly windows could do address space randomization which would make the exploit harder, but it should still be possible even with that.
Re: Anatomy of a hack: 6 separate bugs needed to bring down Google browser
#15Earlier quoted context omitted.
> the limitation that hackers weren't allowed to exploit Windows vulnerabilities He guessed "some predictable addresses allocated by Windows" though. Not detracting from the achievement, but this could arguably be stashed in the non-Chrome side of things.
It's normal, and necessary, for the operating system to provide access to standard library functions; the easiest way to do this is having them at well-known addresses. Admittedly windows could do address space randomization which would make the exploit harder, but it should still be possible even with that.
Admittedly windows could do address space randomization which would make the exploit harder
According to Wikipedia, Windows provides one of the best ASLR on the market. I'm not sure why you are singling out Windows as a weak point here.
Windows has for a long time been the prime target of most exploits, and thus have spent considerable effort, on OS-level, to prevent the potential damage. OS X for instance, has almost none of the OS-level security features found in Windows and is a much easier target to exploit.
http://en.wikipedia.org/wiki/Address_space_layout_randomizat...
Re: Anatomy of a hack: 6 separate bugs needed to bring down Google browser
#16Earlier quoted context omitted.
It's normal, and necessary, for the operating system to provide access to standard library functions; the easiest way to do this is having them at well-known addresses. Admittedly windows could do address space randomization which would make the exploit harder, but it should still be possible even with that.
Admittedly windows could do address space randomization which would make the exploit harder According to Wikipedia, Windows provides one of the best ASLR on the market. I'm not sure why you are singling out Windows as a weak point here. Windows has for a long time been the prime target of most exploits, and thus have spent considerable effort, on OS-level, to prevent the potential damage. OS X for instance, has almos…
> According to Wikipedia, Windows provides one of the best ASLR on the market.
According to the same page, ASLR is enabled only for Windows binaries who had the option set at compile/link time. Also I see no sign of your Wikipedia-attributed affirmation; the article even notes a number of deficiencies.
> OS X for instance, has almost none of the OS-level security features found in Windows
I don't know which precise security features you are talking about, but Mac OS X has been iteratively improving on that front: a limited form of ASLR (along with NX bit and W^X) was available since Leopard for 64-bit processes and was iteratively improved in Snow Leopard and Lion. Full parity was brought to 32-bit processes in Lion. Kernel and kexts are fully randomized in Mountain Lion. Also, as far as I know Windows does not enable NX/DEP for non-system processes by default, and does not implement W^X at all. This is a far cry from 'almost none'.