| |||||||||||||
|
| |||||||||||||
Open Source And VirusesOpen Source And VirusesPosted Jun 4, 2004 22:58 UTC (Fri) by eru (subscriber, #2753)Parent article: Open Source And Viruses One problem in Kannisto's thesis is that it ascribes the spread of all malware to bugs. That is often not so. A lot of it spreads through a combination of socail engineering and ill-conceived ease-of-use features (in particular the ease with which attached programs can be launched in you-know-whose email clients). Open source systems are not innately immune to these effects. For example, earlier versions of GNU Emacs contained an insecure feature of this kind, which would have allowed viewing plain text files to propagate a "macro virus"! fortunately this was fixed many years ago. We can only hope that designers of Linux desktop software manage to avoid these kinds of blunders in the future. I also think Linux maintainers and distribution makers could do more to improve security with little effort. There are patch sets to the kernel that would make exploiting bugs much harder without any runtime costs even on 32-bit x86 (nonexec stack, randomized address layout, better TCP port and sequence randomization), but the features are not in official kernel and not enabled in most distros by default. Why?
(Log in to post comments)
Open Source And Viruses Posted Jun 4, 2004 23:31 UTC (Fri) by JoeBuck (subscriber, #2330) [Link] I think that in another year or so, we'll see more features like those you describe in standard kernels. Red Hat already provides most of them. But there's a price to be paid; these techniques tend to break some software.
Open Source And Viruses Posted Jun 5, 2004 23:52 UTC (Sat) by flewellyn (subscriber, #5047) [Link] A non-executable stack is basically a guard against buffer overflows. If you have, say, a language that does not allow such, by doing bounds checking, then that problem is eliminated.Another problem with non-executable stacks is that some languages, like Scheme and Common Lisp, actually need the stack to be executable. Of course, those languages do bounds checking anyway...
Open Source And Viruses Posted Jun 6, 2004 9:35 UTC (Sun) by eru (subscriber, #2753) [Link] A non-executable stack is basically a guard against buffer overflows. If you have, say, a language that does not allow such, by doing bounds checking, then that problem is eliminated.True but irrelevant. In the real world, most software in use will continue to be written in unsafe languages (and safe languages run in "nocheck" mode, and mixtures of safe languages and unsafe languages) for the foreseeable future. Besides, making a system secure needs "defense in depth": multiple barriers against exploits that are in theory redundant, but in practice aren't, because the implementation of each barrier is not perfect. Another problem with non-executable stacks is that some languages, like Scheme and Common Lisp, actually need the stack to be executable. Of course, those languages do bounds checking anyway... Efficient implementations of those languages (and of Java as well) do indeed generate code on the fly, but that code is placed on the heap, not on stack. An operating system that tries to make data areas non-executable must of course provide some controlled method to convert writable data memory into executable read-only memory, otherwise it cannot support language implementations that use such "just in time" compiling.
Open Source And Viruses Posted Jun 7, 2004 21:56 UTC (Mon) by Ross (subscriber, #4065) [Link] Not really related to worms and viruses but why can't Linux's TCPtimestamps be randomized on a per-connection basis so that the system's uptime isn't visible remotely?
Open Source And Viruses Posted Jun 10, 2004 7:58 UTC (Thu) by nchip (guest, #13292) [Link] ill-conceived ease-of-use features (in particular the ease with which attached programs can be launched in you-know-whose email clients)I used to believe this was a major reason for virus spreading. Then I saw the first viruses that used password protected zip files for spreading. If you can fool users to open a zip file with a password, you can fool an user to save an .sh attachment and open it with /bin/bash. To fend off viruses for good, we need strong sender authentication. Unfortunetly I do not see a way to make using pgp both easy enough for dummys while not compromising security.
|
|
||||||||||||