tag:blogger.com,1999:blog-3024470480937744884.post6158255055207853396..comments2024-03-18T04:40:58.042-07:00Comments on Security: Are we doing memory corruption mitigations wrong?Chris Evanshttp://www.blogger.com/profile/01004765479735675808noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-3024470480937744884.post-75995650644389081942017-05-25T00:07:41.233-07:002017-05-25T00:07:41.233-07:00The split stack stuff is what some CFI solutions (...The split stack stuff is what some CFI solutions (e.g. CPI) do, and basically also what Intel CET does (shadow stack for return addresses), but it only covers the case where you actually want to mount a ROP attack. There are a number of data-only attacks that rely on memory corruption and do not need to corrupt the saved return address.<br /><br />You also ask why there are two pointers: that's mostly to ease debugging when chaining together frames. The use of the base pointer is not required by the architecture, x86 can do just as fine using EBP/RBP as a general purpose register: e.g. see -fomit-frame-pointer GCC option.lazytypedhttps://www.blogger.com/profile/13599338725244459025noreply@blogger.comtag:blogger.com,1999:blog-3024470480937744884.post-65088383905012972752017-05-24T11:09:42.331-07:002017-05-24T11:09:42.331-07:00This idea isn't exactly new, but why don't...This idea isn't exactly new, but why don't we simply split the stack? Like having one for data and one for return addresses. So even if the data stack overflows, we wouldn't need such things as control flow integrety, because return addresses can not be overwritten with a simple memcpy stack overflow. And to protect against data corruption we still have stack cookies. <br />That should even be possible with x86 cpus. <br />Basepointer for return addresses and stackpointer for data. I mean why are there even 2 pointers? arm can do perfectly fine addressing local variables with stackpointer only. tihmstarhttps://www.blogger.com/profile/00836648897056488628noreply@blogger.comtag:blogger.com,1999:blog-3024470480937744884.post-14307382427869083602017-05-16T03:49:13.431-07:002017-05-16T03:49:13.431-07:00Rust is very interesting as it eliminates memory c...Rust is very interesting as it eliminates memory corruption, use-after and data races bugs with no overhead compared to C/C++. It relies on static analysis at compilation to guarantee that.<br /><br />https://www.rust-lang.org/ eksehttps://www.blogger.com/profile/16232667801876603914noreply@blogger.comtag:blogger.com,1999:blog-3024470480937744884.post-5098604604031679612017-05-16T00:49:29.245-07:002017-05-16T00:49:29.245-07:00In SPARC, we've added to the architecture Appl...In SPARC, we've added to the architecture Application Data Integrity (part of Silicon Secured Memory), which allows us to check at runtime for linear memory corruption, with fairly low impact (to the point that we can enable it at large). The idea behind ADI stems from one of the things you point out above: the VA space is larger than the physical space, so we get extra bits of information that we can use to 'tag' memory. This is has been theorized for a long time, but has always hit a wall when the backing memory left the caching hierarchy. On SPARC, we've solved this by storing the metadata all the way down to the physical DIMM.<br /><br />ADI allows us to write hardened malloc() implementations by simply extending existing ones under two constraints: 64-byte alignment and 64-byte minimum size of tagging. I've covered the theory here: <br /><br /> https://lazytyped.blogspot.it/2016/12/hardening-allocators-with-adi.html<br /><br />You cite MPX, so, perhaps, this comparison is of some help:<br /><br /> https://lazytyped.blogspot.it/2016/12/hardware-buffer-overflow-defenses.html<br /><br />and I'm looking forward to the next release of Solaris to showcase how we've leveraged it system wide for different bug classes ;) (the amount of incorrect handling that just popped up across the board by throwing test suites to run under our new defenses has been pretty fascinating)lazytypedhttps://www.blogger.com/profile/13599338725244459025noreply@blogger.com