5 ms·
"Strong" stack protection for GCC
- d0 13y agoIsn't this the same as what the OpenBSD guys added to their GCC fork? I think it was called ProPolice.
- Someone 13y agoAccording to http://en.wikipedia.org/wiki/Buffer_overflow_protection#GNU_Compiler_Collection_.28GCC.29 http://en.wikipedia.org/wiki/Buffer_overflow_protection#GNU_..., it was IBM that developed ProPolice, and this is an evolution of a reimplementation by RedHat.
- d0 13y agoGotcha - thanks for the correction. Checked my sources and it was W^X they implemented at the same time as ProPolice and indeed it was IBM who built that.
- willvarfar 13y agoI know everyone is a bit tired of hearing about the new Mill CPU, but one of the things we've done with the architecture is to have the hardware track return addresses. This is not only much faster and efficient; it is also immune to these kinds of attacks. There's an upcoming "Security" talk which will cover lots of other ways we've worked to improve the fundamental protection offered by the CPU, but the stack is covered in the Memory talk: http://ootbcomp.com/topic/memory/ http://ootbcomp.com/topic/memory/ and ootbcomp.com/topic/introduction-to-the-mill-cpu-programming-model-2/
- pohl 13y agoI know everyone is a bit tired of hearing about the new Mill CPU Well, damn, I must be late to the party. The Mill just caught my attention a week ago, and I'm far from being tired of hearing about it. Thank you for sharing what you can.
- nhaehnle 13y agoAs has been pointed out on the LWN thread, buffer overflows even on the stack can also leave you vulnerable by overwriting other automatic variables, e.g. a variable that indicates whether a client is authenticated as an administrator.
- willvarfar 13y agoYes this is completely true. I meant particularly the return-to-libc type of attacks that the canary (to some extent) protects against, when I claimed immunity (and improved performance). We have some stuff to talk about on the protecting authentication flags and things front too, but I'm afraid that'll have to wait for the Security talk. One other security-related aspect that we have already presented is how stack debris is not readable once returned, so malicious code can't go looking at it. We've also talked a little bit about how we don't have rings, and we have very cheap syscalls across protection boundaries. So there are some hints of stuff to come.
- mparlane 13y agoROP chains.
- emillon 13y agoOn the conceptual level, ROP and return into libc are the same thing. You need to start them by overwriting an address somewhere, and the return address is a natural candidate.
- willvarfar 13y agoYes, the Security talk will cover ROP too :). Stay tuned. The Mill is far from exploit-free, but vast swathes of attacks can be stopped or mitigated and we do our best.
- habitue 13y agoKnuth's MMIX[0] architecture also has a "hardware" stack (scare quotes because it isn't implemented in real hardware) [0]http://en.wikipedia.org/wiki/MMIX http://en.wikipedia.org/wiki/MMIX
- pjmlp 13y agoI am not, I love to learn about new architectures.
- neur0mancer 13y agoI wish all distros will start compiling all its packages with a consistent policy to enable at least some level of stack protection (like Ubuntu and unlike Debian).
- gizmo686 13y agoDoesn't Ubuntu take most of their packages from Debian?
- habitue 13y agoUbuntu uses the packages that have been maintained and integrated by Debian, but they don't necessarily take the binaries. They compile it themselves, and that means they can specify whatever compile options they want.
- dima55 13y agoCan you elaborate? Debian has infrastructure for hardening their builds (look on their wiki), but each package has to make sure to use it. Unless Ubuntu patches each package source (which they don't), then they have the same hardening status as Debian. Where did I go wrong?
- pjmlp 13y agoHow would the computing world be, if compiler and OS vendors weren't required to keep on fixing the issues caused by C's widespread into the industry?
- twoodfin 13y agoIf C did not exist, it would be necessary to invent it. There is CPU-bound code out there, where every cycle saved in an inner loop equates to hours of improved runtime or thousands of additional client transactions/second. Safer languages have made great strides in the kinds of dynamic profiling and optimization that can equal the performance of optimized C/C++, but there remain real penalties in startup and profiling time.
- oofabz 13y agoHow about Ocaml or Rust? They are both safer than C and are almost as fast. I don't think we'd reinvent C on modern machines, which have millions of times more memory than K&R had to work with on their PDP-7.
- habitue 13y agoI think some things like null terminated strings etc are not inevitable in a fast language like C. There were definitely design mistakes that cost security and don't directly affect performance significantly.