| |||||||||||||
|
| |||||||||||||
Distribution of security fixesDistribution of security fixesPosted Aug 26, 2004 2:13 UTC (Thu) by jreiser (subscriber, #11027)Parent article: Distribution of security fixes Unfortunately, this didn't occur to the glibc implementors, who did not add any checks for setuid operation in the LD_DEBUG code. Disabling such a check is early on malware's list of things to do, and it is easy: for instance, replace one conditional branch instruction with a NOP. If security really is an important goal, then SUID executables deserve their own separate libraries, or no libraries at all. And there should be a kernel flag option to mmap()/mprotect() which says, "No changes allowed to this vma, except deletion at exit()." What should not be an option is keeping security fixes to ones self. That depends on the economy-of-the-day. Sometimes exclusive knowledge of a vulnerability, how to exploit it, and/or how to fix it, is worth much more than what is available in the "gift economy," particularly in the short term.
(Log in to post comments)
Distribution of security fixes Posted Aug 26, 2004 3:42 UTC (Thu) by Ross (subscriber, #4065) [Link] If they are able to edit the library on disk or in RAM then the game isalready over. I fail to understand your point.
Distribution of security fixes Posted Aug 26, 2004 14:42 UTC (Thu) by jreiser (subscriber, #11027) [Link] A successful exploit might depend on the rate and amount of change from "good" to bad memory image: the smaller the number of bits that must be changed, and the smaller their range of addresses, sometimes can make it easier to accomplish.
|
|
||||||||||||