Re: Windows vulnerability vs Linux vulnerability [Re: Would a firewall
From: Grant Wagner (gwagner_at_agricoreunited.com)
Date: Fri, 07 May 2004 14:57:55 GMT
"Lars M. Hansen" wrote:
> On Thu, 06 May 2004 10:20:40 -0400, Rowland spoketh
> >1. Windows has far more security problems than Linux or other Unix
> >variants. Microsoft' defenders have about half a dozen excuses for this
> >and none of them impress me.
> The biggest issue isn't Windows Network administrators, it's the home
> user who just got his/her computer from Dell or Gateway, and just plugs
> it in without knowing that things are not kosher. I admit (as both a MS
> and Linux proponent) that there are default settings in Windows that are
> plain and simply set wrong. Services are running that in most cases
> shouldn't be and registry settings that could prevent some exploits are
> not set correctly. The registry fix for the recent DCOM vulnerability
> takes about 10 seconds to fix (plus reboot)...
Agreed. And we're right back to the argument that if Linux were as widely
distributed in the consumer market as Windows is, we'd see just as many
attacks and worms hitting Linux.
Ma and Pa Kettle just home from Best Buy with their shiney new Red Hat 7 PC.
They turn it on and use it cause it's so user friendly and all. They get
warned about "downloading updates" (I dunno, does Red Hat 7 even have
auto-update capabilities?), but they don't see the point in "wasting their
time doing that computer stuff". Soon they get hit with a sendmail or apache
worm and are acting as a drone for someone to attack other unsecured Red hat
Linux zealots look at the above and scream "BUT LINUX IS MORE SECURE FROM THE
BEGINNING" (it isn't) or "BUT ALL YOU HAVE TO DO IS RUN UP2DATE AND IT FIXES
EVERYTHING" (true, but Ma and Pa Kettle don't care about doing that).
Well, you know what? All Windows users have to do is leave Auto-update
ENABLED (which is how it comes by default I believe, although I could be
wrong), and patches from Microsoft would either be INSTALLED AUTOMATICALLY,
or, if they prefer, they can be informed of the updates, have them downloaded
and install them at their leisure. People choose not to take advantage of
this, or they are running a pirated version and can't connect to
windowsupdate, or they are convinced Microsoft is stealing their thoughts
when they connect their PC to windowsupdate and refuse to do it.
The reason you don't see as many Linux worms is not because there are not
holes there to be exploited, but because most people running Linux are
administrators running them as servers (so they are secure) or people who
have an active interest in computers and computer related technology (so they
secure their PCs). The few remaining Linux installations run by the clueless
masses aren't worth targeting. It's much more "fun" to target millions of
Windows systems. Once Linux gains the consumer popularity desired by the
Linux community, that will change.
> >3. The majority of Linux/Unix vulnerabilities have to do with buffer
> >overflows. So do a large chunk of Windows vulnerabilities. So there
> >are two problems here: Microsoft, and buffer overflows.
> No, the problem is bad programming by everyone. Unless programmers
> suddenly get perfect over night, we'll end up with buggy software on all
Managed code in .NET will resolve some (but admittedly not all) of this. Much
of Longhorn is being written using managed code, there will be no
opportunities for buffer-overrun attacks in a system that can't have a
buffer-overrun. As well, 64-bit Windows will support some CPU's concept of
"executable code blocks", where applications can mark areas of memory that
are executable. I'm not sure how many developers will actually take advantage
of this, but it is there.
<url: http://forums.gizmobytes.com/index.php?showtopic=940&st=0& /> (not the
most reliable source, but it describes the features of the AMD 64-bit CPUs)
For those without PowerPoint:
Goal and customer benefit
- Reduce exposure of some buffer overruns
What we’re doing
- Leverage hardware support in 64-bit and newer 32-bit processors to only
permit execution of code in memory regions specifically marked as execute
- Reduces exploitability of buffer overruns
- Enable by default on all capable machines for Windows binaries
- Ensure application compatibility with NX for Longhorn
- Ensure your code doesn’t execute code in a data segment
- Ensure your code runs in PAE mode with <4GB RAM
- Use VirtualAlloc with PAGE_EXECUTE to allocated memory as executable
- Test your code on 64-bit and 32-bit processors with “execution protection”
-- | Grant Wagner <firstname.lastname@example.org>