Recent Features
| |||||||||||||
Security in the 20-teensSecurity in the 20-teensPosted Feb 5, 2010 5:56 UTC (Fri) by Ford_Prefect (subscriber, #36934)Parent article: Security in the 20-teens
"Some of these problems (yet another PNG buffer overflow, say) appear to have a relatively low priority, but they shouldn't."
I wonder why such attacks are still relevant - just about every modern processor now allows you to mark only code pages as executable and read-only (NX bit and the like).
(Log in to post comments)
Security in the 20-teens Posted Feb 5, 2010 13:30 UTC (Fri) by tialaramex (subscriber, #21167) [Link]
Read the Prologue to "A Fire Upon The Deep". Ultimately the difference between acting on some untrusted data and executing untrusted code is only a slight matter of degree.
Suppose the buffer that you overflow is next to a variable named 'fd'. You replace the file descriptor of a file being written with that of an open network connection, and suddenly data intended to stay local pours uncontrollably out onto the Internet...
The moment progam behaviour deviates from what was intended by the programmer / user you have a potential security hole. If you're lucky it amounts to nothing, and you can invent countermeasures to make that more likely, but it's not safe to bet on it, and the more resourceful and determined the attacker, the more certain they'll find a way to make it work.
And inside a web browser (the most obvious thing to attack) the idea of "non-executable" is laughable. So what if I can't change the machine code, I can scribble on the "mere data" like the trusted Javascript, Flash or Java byte code, which will get executed for me by a virtual machine and have the advantage of being portable.
Security in the 20-teens Posted Feb 8, 2010 22:55 UTC (Mon) by mrdoghead (guest, #61360) [Link]
So what if I can't change the machine code indeed. With a mere browser-level deception and injection you can have the user change the system for you at the next restart, alerting you by whatever protocol you prefer silently at the next time thereafter that the machine comes in range of a radio connection or wire that your new machine awaits. And while developers and their tools are a prime target of people who want access to our machines and every system I know of has purposely commited "flaws", as they're described when exposed, the machine code is and has been where the real action is. Hardware is a cesspool of backdoors and security defeaters, some legally imposed and others not. There's much money and interest riding on machines being indefensible. Do people have the stomach to advocate against governments, corporations, and criminals too? When law enforcement is on the other side requiring indefensibility? And remember, a piece of working, innocuous code is just a context shift and reparsing away from being quite malicious, no recompiling required.
Security in the 20-teens Posted Feb 11, 2010 9:36 UTC (Thu) by renox (subscriber, #23785) [Link]
>You replace the file descriptor of a file being written with that of an open network connection,
For a security perspective, the PNG decoder shouldn't have access to network sockets..
>And inside a web browser (the most obvious thing to attack) the idea of "non-executable" is laughable.
Agreed, that's why Chrome's design is really a nice change here, even if it doesn't go far enough: AFAIK Flash isn't properly 'shielded' from the rest of the system..
Security in the 20-teens Posted Feb 11, 2010 14:32 UTC (Thu) by anselm (subscriber, #2796) [Link] For a security perspective, the PNG decoder shouldn't have access to network sockets.. The PNG decoder shouldn't be allowed to open new network sockets. However, a file descriptor open for reading is a file descriptor open for reading. It doesn't matter much whether there is a disk or a web server at the other end.
|
|||||||||||||