| |||||||||||||
Security-improving technologies which could be deployed nowSecurity-improving technologies which could be deployed nowPosted Oct 21, 2004 6:54 UTC (Thu) by joib (guest, #8541)In reply to: Security-improving technologies which could be deployed now by ballombe Parent article: Security-improving technologies which could be deployed now Before asking why such technology is not in Debian or Gentoo, ask why the patches are not merged in linux in gcc by the upstream developers. Here lie part of the answer. GCC has its own libmudflap thingy, whose purpose IIRC is to catch illegal array indexes. Thus it has some overlap with SSP, and gcc apparently is not going to merge it. Which perhaps is a pity, since mudflap is more of a debugging tool rather than something that's supposed to be used for production code.
(Log in to post comments)
Security-improving technologies which could be deployed now Posted Oct 21, 2004 16:37 UTC (Thu) by job (guest, #670) [Link] That actually sounds like a better technique. The performance penalty isprobably a little larger, in the real world but who cares? Has there been any work towards using it as a stack overflow exploit prevention?
Security-improving technologies which could be deployed now Posted Oct 21, 2004 18:01 UTC (Thu) by solar (guest, #17536) [Link] 1-3%(ssp) vs 30ish%(mudflap) is a quite a big deal for production use. I can't imagine any vendor releasing production ready media compiled with mudflap. It may be used to do some QA on the back end before the media is deployed out for the masses but in production probably never.
Security-improving technologies which could be deployed now Posted Oct 21, 2004 21:37 UTC (Thu) by bluefoxicy (guest, #25366) [Link] Mudflap is an excellent technology. I would love to see it forced on developers via a Singapore prison guard holding a cane in one hand and a whip in the other. ;)
That being said, deployment of software built with Mudflap is a horribly bad idea. Mudflap is made to be a debugging tool, not a security tool, and has no place in use in production. It is there to help the programmer polish his program, not to play goalie on your web server.
The combination of the technologies is an excellent prospect. On the developer's end, things such as Mozilla are built with Mudflap. These binaries give a load of information about what is broken, which is used to fix that. The binaries shipped to regular users are instead compiled with SSP and without Mudflap. These binaries will run much more efficiently, and will dterminate if a buffer overflow bug still exists and is manifested, such as during an attack.
Let's also note that most software will run fine until attacked with SSP. This shows that the buffers aren't being overflowed in normal use. If they are not overflowed, Mudflap will probably not see anything wrong, and thus will be deployed a vulnerable program. Upon being exploited, SSP will terminate the program, and as a bonus feed back a little bit of data which can be used to track down where the bug occurred.
Both technologies have their uses, and both should be used gratuitously.
|
|||||||||||||