> >If you can feed a program enough data that it starts executing opcodes
> >that you've fed it in a carefully constructed command line the
> security
> >game is lost unless the operating system can prevent that program
> >from further compromising the system or opening further holes.
> Assuming the process you've done your buffer overrun attack on is
> running as SYSTEM (NT's equivalent to root).
Not on a firewall. On a firewall it can run as any user and perform a
SATAN style attack on hosts beyond the firewall. Whether it can subvert
internal security on the firewall is less critical. But even there, the
gaps Microsoft has created in NT security (bypassing traverse checking,
for example, and the lax permissions you need on system directories) make
a trojan horse attack (via the file system or the registry rather than
the secured portions of the proxy, for example) quite credible. A similar
attack in UNIX, from a chrooted environment, is orders of magnitude more
difficult.
> I hate to think all the other answers I gave you about this were
> fake...;-]...but this isn't actually correct. Its not NT that isn't
> built that way, its the application its running that might not be built
> that way.
NT is not just the kernel and subsystems, it's got to include the applications
as well. Just as people consider sendmail holes to be a UNIX security problem,
the configuration problems and problems in Microsoft applications and
utilities are NT security problems. NT, as a system, has not been given
the same overall attention to security as UNIX. And that's truly scary,
because UNIX was not originally designed with high levels of security as
a goal!
> It should be remembered that NT is re-written by each of the different
> processor groups from the HAL through the Kernel on up. Much of its
> isn't, but its all scrutinized by the programming teams for the Alpha,
> PowerPC, and soon to be defunct MIPs vendors. These are not small teams
> of programmers sitting waiting to be told what to do by Microsoft, nor
> are they Microsoft employees. These people have a vested interest in
> examining the code and do so with diligence. To say it doesn't get
> scrutiny outside of Microsoft is a fallacy.
I didn't say that. What I said is that *I* can not scrutinize the source.
Whether some programmer subject to a nondisclosure agreement has seen it
is utterly irrelevant to me: his study doesn't benefit me any more than a
similar study by a Microsoft programmer... unless I'm already a criminal
and are willing to coerce him into violating his NDA.
That is, Microsoft's secrecy regarding their source, while completely
understandable, does benefit the black hats by keeping most of the white
hats away. Most especially, it keeps away the people who will perform the
same sort of hostile reviews that have publicised AND CLOSED so many UNIX
holes.
|
|
