[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
Keith Abraham wrote: > Just read this and thought it might be of interest. > > http://www.globetechnology.com/servlet/story/RTGAM.20050818.gtwormaug18/BNStory/Technology/ > > > It's not so much the content as the air of growing mistrust of Microsoft > that lies behind it. The article suggests that business users blame Microsoft for the software flaw that made it possible (buffer overflow in PnP). You have to have PnP port exposed to the Internet - which would have got your PC owned a long time ago, as there were previous exploits against PnP. For most business this would be simple negligence. However I'd suggest this type of flaw itself, if not the decision to expose it by default, is very common in Linux. Indeed those running with listbugs in Debian unstable will probably knowingly install components with flaws of this type about once a month. > And it makes the proposal of the MOD to ditch Unix in favour of > Windows 2000 for RN warships even more frightening? My concern here is summed up nicely by the Multics audits. Which got referred to in a discussion elsewhere this week. http://www.acsac.org/2002/papers/classic-multics.pdf http://www.acsac.org/2002/papers/classic-multics-orig.pdf Effectively points out that one of the simple but big differences is Multics was written in PL1, making writing buffer overflows hard, where as many of the modern buffer overflows are due to trivial human error on the part of C programmers, because C makes it easy to write buffer overflows. But also that other basic protections in Multics just don't apply, in some cases because no one bothered using available hardware features (Portable Linux versions can be especially bad at exploiting platform specific hardware features, for obvious reasons). Note also the SANS institute have returned their Internet watch to Yellow alert (it dropped to Green after worms exploiting MS05-039 were released - no point in alerting people to split milk). The reason is the MSDDS.DLL exploit. The issues around this one highlight flaws with the defaults used for ActiveX components. Again it the exploit works because of poor defaults, but also lack of architectural protection against executing data, which is common to many off the shelf Linux distros. Does anyone know of a page listing the different types of protection against these types of exploit and which Linux distros, and free software OSes, have which by default? Fedora Core has exec-shield installed and active by default. Obviously the "secure" distros do various extra things for these types of problem, but it would be good to highlight the issue I think. Although of course the simple diversity of Linux may help, it also runs the risk of making it more complex to write portable code if different distros get radically differing security features. I think Linux (and Linus) would be well advised to pick the best solution so far and standardise it. I'm sure it is an area the free software world can move faster in, if it chooses and has some direction. And to be able to clearly state - Linux doesn't have this kind of problem (from kernel 2.6.?) - rather than saying "neither Redhat Fedora Core, not Trustix, have this problem but I'm not sure about <insert other Linux distro>, and you'll have to patch and recompile your kernel to get it on <other distro>" is not the kind of message the end user will want to hear (or even understand). Retro fitting these things as a VAR, means risking breaking the distro - say I built my own Debain Sarge kernel image with these features added, I can never be sure that a new patch won't break a key application till I'm sure the patch writer have a similar kernel build. Simon -- The Mailing List for the Devon & Cornwall LUG Mail majordomo@xxxxxxxxxxxxx with "unsubscribe list" in the message body to unsubscribe. FAQ: www.dcglug.org.uk/linux_adm/list-faq.html