Re: Of mice and men


In article <1115756739.415801.135880@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, "Richard" <riplin@xxxxxxxxxxxx> writes:
> > With Windows there is a small finite number of configurations.
>
> > You have either a very strange idea about combinatorics, or a very
> > strange definition of "small".
>
> The reason that it is relatively small is that Windows software cannot
> be recompiled by the user.

A great deal of it can be - but the point is moot, anyway.

> Thus for a particular module the exact byte
> layout will be as Microsoft issued it, either an original issue, or a
> later patched version.

That doesn't matter, because exploit technology is no longer very
sensitive to precise code layout. Look at what's being posted to
VULN-DEV these days. Look at all the articles being published in
places like _Phrack_ (before its recent demise) and _2600_ on
adaptive attacks.

> > *not* "especially true of buffer overruns".
>
> The reason that buffer overruns work is that the data sent overlays
> areas outside the buffer.

Thanks, but I know how buffer overruns work. I just gave a presen-
tation demonstrating how to use them against COBOL programs (to
combat the widespread belief that buffer overruns are exclusively a C
issue). Wrote my own execute-on-stack and return-into-libc exploits
and shellcode. It's a simple task.

> Random bytes written to random variables will
> most likely just crash the system. Geting specific values into
> particular places may allow code to run which will be malicious.

The bar is nowhere near that high.

> With Windows there is a small finite number of variations of each
> module so a particular set of data when overruning a buffer has a good
> chance of working by finding it is in a module that has the correct
> layout.
>
> With Linux it is likely that many different distros or versions are
> different enough even if it hasn't been recompiled.

Simply not true. "Different enough" turns out to be far more
different than you seem to believe, and certain builds are in fact
widely installed on Linux systems, because many administrators use
pre-built binaries.

> Just one byte
> difference in an address can prevent the overrun working.

This is extremely unlikely for the sorts of exploits being developed
today (and indeed for the past several years).

> > What distribution was immune to CAN-2004-1137 ?
>
> """ ... to cause a denial of service or execute arbitrary code ..."""
>
> > those apply to all the machines running that kernel version
>
> No. That is not true:

Since you conveniently snipped my qualification that it applied to
machines with that code compiled into the kernel, or running in a
loaded kernel module, this is a misquotation and a strawman argument.

> Buffer overruns on Windows have been exploited to load malicious code
> remotely via, say IIS.

As they have on Linux, and on other Unix-derived systems. Moot point.

> The security impact of loading malicious code is much more significant,
> and is much more likely to be successful with Windows because there are
> only a small number of possible alignments: maximum of one for each
> version issued by Microsoft, and these can be determined.

This argument also demonstrates a fundamental misunderstanding of the
NT loader, which need not load a module at the same address each time.

> > Security by obscurity is not a defense.
>
> That is what OSS say about closed source ;-)

Eggs, grandmother, instruction. I've been an observer and occasional
researcher in the software security world for the better part of a
decade now.

> But, in fact, it is how vaccinating a population works. If a large
> part of the population is vaccinated then this also protects most of
> the unvaccinated part.

Spare me the "monoculture" arguments until you have some empirical
evidence showing that they hold, please. I've read them all before.

I've been a Unix developer since 1987; a Windows one only since 1988
:-). I prefer Unix. I certainly prefer its security posture. I
prefer OSS (though I have no religion about it - I'm perfectly happy
to be developing proprietary software). But I don't allow my prefer-
ences to become illusions about the relative security of Windows and
Unix OSes. They're all *inherently* pretty bad; they all have poor
security decisions inherent in their designs. (Windows has far too
much running in privileged mode, for example; Unix has too shallow a
privilege hierarchy, and security features like chroot which have
become liabilities because they fail to uphold their contracts.)

Roughly-equivalent security - that is, similar attack profiles under
similar threat models - can be achieved with current versions of
Windows and Linux. It's still more work with Windows, and Windows
users still generally need more training. But Linux does not have
any compelling *inherent* (in the design) security advantage. Both
OSes are designed to meet similar security criteria, and in the larger
security picture their differences are quite small indeed.

If you want to believe that Linux is inevitably more secure than
Windows, fine; that belief has been useful for a lot of people, not
all of them the administrators of the Linux systems under attack.

--
Michael Wojcik michael.wojcik@xxxxxxxxxxxxxx

Americans have five disadvantages which you should take into account
before giving us too hard a time:
- We're landlocked
- We're monolingual
- We have poor math and geography skills -- Lucas MacBride
.

Relevant Pages
Loading