[LINK] Security: from a different direction

Craig Sanders cas at taz.net.au
Thu Dec 16 10:09:30 EST 2004


On Wed, Dec 15, 2004 at 06:36:41PM +1100, rchirgwin at ozemail.com.au wrote:
> >the main point of my last message was that you can't trust your
> >firewall software because it's just another windows application. any
> >virus or worm or whatever that does get through your defenses can
> >disable it or reconfigure it - or even replace it with a trojaned
> >version that *appears* to be configured and working correctly, but
> >secretly allows the virus to do whatever it needs to.
>
> That's a kind of infinite regress. At some point, the user has to
> decide what to trust.

perhaps.  but there is a big difference - with linux there is good reason to
trust the underlying system, but with windows it is just wishful thinking.

> Now; I think the decision to trust the firewall software, which is    
> behind a NAT anyhow (and not using static addresses), is defensible.  

you probably gain more protection from the NAT device than from your firewall
software.  at least, you can trust that it's far less likely to be subverted.

> In particular, because the next step up (to a *nix or BSD OS) would
> carry with it a huge information load at entry point; no, not
> "installing" which is easy enough, but working out all the tricks and
> behaviours of usage, plus learning how to secure from scratch. I would
> probably end up with a less secure system for "time X", only because I
> know I can't instantly learn from scratch.

1. it's not as hard as you think.  you seem more than capable of learning
how to implement decent security on *nix.

2. it's reasonably secure "out of the box", and it doesn't take much 
to tighten up the security,

3. it doesn't just break by itself - you have to do things to undermine the
security on linux, if you just leave it alone (and upgrade regularly) then it
will continue to be secure. 

4. (and this is important) you can't secure *anything* without having a solid
understanding of security basics.  these principles are transferrable across
operating systems.  you need to learn this stuff anyway if you connect a
computer to the internet, regardless of whether you run windows or linux or mac
osx or whatever (but linux and osx and other *nixes give you much better tools
to implement the security principles).


> > the reason for this is simple:
> >
> > there is no priviledge separation in MS Windows. it is not possible
> > to stop any program from doing whatever the author wants to the
> > system, regardless of whether it is being run as Administrator or as
> > a normal user.
>
> It is, however, possible to stop 'any program' from executing without
> permission.

no, it isn't.

you may be able to stop a *co-operative* program from executing, if the author
wants to play by the rules.  but virus and worm and trojan etc authors don't
do that.

remember that they are exploiting bugs (and bad design decisions, and
"convenience" features) in the operating system and in the applications to make
the target systems do things they're not supposed to do.

for example, making outlook execute allegedly-jpeg attachments, and buffer
overflow errors on the code that parses the Date: header (which allowed
arbitrary code to be executed).

it doesn't matter what the application is or what the bug is, as soon as it
has been tricked into executing something that it shouldn't, then the entire
system can be changed to suit the attacker's needs.

viruses etc are fairly sophisticated now.  they are only going to get more so
in future - as more people use things like ZoneAlarm and sypbot detectors etc,
then virus writers will add more routines to disable/subvert them to their
toolkits....and since the underlying system is completely insecure it doesn't
matter how much or what kind of security you layer on top of it.  security is
only as strong as the weakest link in the chain, and windows is an
extraordinarily weak link.



> > b) most home users don't bother with it, they just have a single
> > login
>
> True. I don't!
>
> > c) many applications (esp games) only run if the user has
> > Administrator privs, so many home users just run as Admin or give
> > their "login" admin privs.
>
> As previous, if the app doesn't play nice, it doesn't play in my yard.

how would you know if it doesn't play nice if you don't even have a separate
admin account?


> Yes, I have a way of knowing. The vendor's checksum. Or if I don't trust 
> the exe, I reinstall. Heavens, if I can't read source code, I can't 
> treat OSS as intrinsically trustworthy; I have to decide to trust 
> someone else. You and I both choose to end the regression somewhere, we 
> just do so in different places.

you're right.  OSS is not intrinsically trustworthy - but more people are
looking at it, so there are many more opportunities for bugs to be found and
fixed.  even more importantly, even if there is a bug in some application, it
can't do much damage unless it is run as root (this is why most daemon
processes don't run as root, they run as a dedicated user...and those which
need root privs for some reason tend to do that in a small, easily debugged
module which does the root stuff and drops privs as soon as they are no longer
needed).

also, see comment above re: reason to trust vs wishful thinking.

a whole bunch of unconnected geeks, with no financial or job-security motives
for keeping problems secret (and indeed, an ethic which demands that problems
be disclosed to the public), is far more trustworthy than some corporation that
has financial motives for bug secrecy and is constantly being embarrassed by
slack security.  MS has shown repeatedly that they will ignore and even hide
problems until someone else discloses it to the world, only then will they
attempt to do something about it.  in the meantime, there's an open hole with
exploits being written for it.

i can reasonably trust linux because i know that if there is a problem
discovered, i'll get to hear about it quickly.  and if there is a fix, i can
apply it.  if there isn't one, i can choose whether or not to run the
vulnerable service/application until it is fixed, or take extra precautions to
be able to use it safely.


craig

-- 
craig sanders <cas at taz.net.au>           (part time cyborg)



More information about the Link mailing list