Mailing List Archive

On Mon, 15 Jul 2002, Schmehl, Paul L wrote:

> That depends on how the admins configure things. :-) Here at UTD, for
> example, it isn't possible to execute a VBS file unless you know what
> you're doing.

Well, that's very good. How about .exe?

> It's also possible to restrict the executables that a
> user can run, using group policies.

Yes, it is. How much work is it to set all this up?

[...]

> And you think they will do *better* at this in *nix? You've pinpointed
> the problem, but missed the solution. The problem is the *users* who
> are ignorant and chose to remain that way. The solution is for the
> *conscientious* admins to understand that truth and find ways to defend
> the enterprise *anyway*.

That's true. Nevertheless, I contend that it's easier for
conscientious admins to protect UNIX boxes from ignorant users
than to protect Windows boxes (period.)

In fact, UNIX boxes are extremely easy to protect from the truly
computer-ignorant, and they're not bad for experts. It's the people
in the middle who are dangerous on UNIX boxes. :-)

For example, my parents run Linux at home. They are complete
computer newbies. So I set everything up for them, locked down all
the permissions, and they're fine. An occasional VNC session over SSH
is all the help they need from me.

Some of the people I've worked with, however, know enough about UNIX to
be dangerous and often screw things up...

> Your ignorance of Windows is showing. It is possible, under all
> "modern" versions of Windows (not the 9x variety) to get as granular as
> this (at the directory or file level):

I fully admit to ignorance of the details of Windows security, although I
believe I grasp the overall situation.

> Full Control
> Traverse Folder / Execute File
> List Folder /Read Data
> Read Attributes
> Read Extend Attributes
> Create Files / Write Data
> Create Folders / Append Data
> Write Attributes
> Write Extended Attributes
> Delete
> Read
> Change
> Take Ownership

These are granular indeed, and confusing as hell. A good security model
should be simple; the Windows one is anything but. I can probably outline
the UNIX security model in 300 words. I challenge any Windows user to do
the same for Windows.

And complexity is the enemy of security. It can lead to misunderstanding,
incorrect implementation, and ambiguity.

> It isn't the OS that's the problem.

I disagree. The design of the OS is a large part of the problem. (I
say "OS" here to include Microsoft applications like IE, which (after
all) Microsoft insists are part of the OS.)

> It's the manufacturer's choices of
> default settings and the ignorance of the users (and admins in many
> cases.) Isn't this precisely the same problem on *nix? Give me an
> ignorant user on a default install of *nix and I'll give you a hacked
> box in a few minutes (except perhaps OpenBSD, which is one of the few
> that ship "secure" out of the box.)

That may have been true 3 or 4 years ago, but (at least in the Linux and
*BSD worlds) is no longer. The default installation settings are
pretty good nowadays.

> Please don't misunderstand - I am NOT saying Windows is a good as or as
> secure as Unix. Given the choice, I'll take OpenBSD. But the *real*
> problem isn't software, it's humans.

I'm not arguing with you on that point. But I think it's correct to
say that any organization interested in long-term security planning
should consider weaning itself away from proven-insecure software.
Microsoft's track record is really terrible, and I don't see any
indications that things are changing. How much benefit of the doubt
do vendors deserve, anyway?

--
David.

On Mon, 15 Jul 2002, Schmehl, Paul L wrote:

[SNIP]

>
> It isn't the OS that's the problem. It's the manufacturer's choices of
> default settings and the ignorance of the users (and admins in many
> cases.) Isn't this precisely the same problem on *nix? Give me an
> ignorant user on a default install of *nix and I'll give you a hacked
> box in a few minutes (except perhaps OpenBSD, which is one of the few
> that ship "secure" out of the box.)
>
> Please don't misunderstand - I am NOT saying Windows is a good as or as
> secure as Unix. Given the choice, I'll take OpenBSD. But the *real*
> problem isn't software, it's humans.


You hit on the duality of the issue<s> beofre trying to refine it into a
plurality issue. The *real* problem is vendors relasing bugy code with
insecure defaults which *promotes* users remaining clueless. take a look
at the wireless issues spewing into the airwaves now, and look at not only
the default installs of the products available for playing with wireless
toys and trikets, but, take a serious look at the documentation and how
much is devoted to the issue of securing the toys. For example, take a
look at the pdf manual for the d-link dwl-650 wireless net card, 80 pages
of which about 2 pages are devoted to trying to secure the devices in any
fashion via wep, not that wep is all that secure, but, it beats nothing
<the default>. Or consider this, even if a vendor 'attempts' to do
something less then a default open braodcast:

Orinoco RG-1000 residential gateway is reported in past advisories to
ship with WEP enabled; From: Bill Arbaugh <waa@CS.UMD.EDU>
Subject: RG-1000 802.11 Residential Gateway default WEP key
disclosure flaw Date: Mon, 2 Apr 2001;

Unfortunately, the default
WEP key is set to the default network name, SSID. The
SSID appears in several 802.11 management frames in
the clear-- even when WEP is enabled. Therefore, an
attacker with a sniffer capable of capturing
management frames can determine the current WEP key
which is the last five digits of the network name,
(provided the default has not been changed). Armed
with the network name, and the current WEP key the
attacker can easily gain access to the users wireless
LAN. Additionally, the default network name for the
unit studied was the last six nibbles of the MAC
address converted into ASCII [1]. As a result even if
the key were not the network name, an attacker could
determine it by sniffing the MAC address of the unit.

To Lucent/Ornioco's credit, the fact that the default
encryption key should be changed is strongly
encouraged in the manual. However, the fact that the
default key is disclosed in the clear as part of the
network name is unfortunate. The default encryption
key should be changed to a randomly generated value
set at the factory.



The moral to this is, don't just beatup on the users, but, get ugly with
the vendors and force them to pay attention to security as well, and force
users to shoot themselves in the foot rather then just shooting em in the
head from the beginning.

If openbsd only tried to do things half-assed, they certainly would not
get the allcolades they do from the user comunity here.

Thanks,


Ron DuFresne
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Cutting the space budget really restores my faith in humanity. It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation." -- Johnny Hart
***testing, only testing, and damn good at it too!***

OK, so you're a Ph.D. Just don't touch anything.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>>>> "Ron" == Ron DuFresne <dufresne@winternet.com> writes:

Ron> [snip]

Ron> You hit on the duality of the issue<s> beofre trying to
Ron> refine it into a plurality issue. The *real* problem is
Ron> vendors relasing bugy code with insecure defaults which
Ron> *promotes* users remaining clueless. take a look at the
Ron> wireless issues spewing into the airwaves now, and look at
Ron> not only the default installs of the products available for
Ron> playing with wireless toys and trikets, but, take a serious
Ron> look at the documentation and how much is devoted to the
Ron> issue of securing the toys.
Ron> [more snip]

I agree that vendors are responsible for security issues to quite an
extent. As far as I can see, there are three real issues for security
from the vendor point of view:

1. Insecure defaults. Many vendors will sacrifice security in favour
of usability. This, for some reason, seems to be even more true in
the Windows world than in Linux/*BSD/Unix, where vendors try to at
least make things usable but with as good an underlying security layer
as possible. Redmond doesn't appear to give a d*mn about end-user
security, as long as the user has a `clean, comfortable, easy usage
experience'. Definitely the vendor's responsibility.

2. Insecure design and coding. IMO open source/free software has an
edge here, since most of the developers don't have to work against
release deadlines, unlike the proprietary software vendors. I don't
accuse MS (or anyone else) of deliberately making insecure software.
I do accuse them of bowing to marketing pressure and hence sacrificing
due diligence in making software secure.

Further, the free software model encourages reuse of components, and
my uneducated guess is that as time passes the more secure components
automatically float to the top of the heap whenever reuse becomes
necessary.

Of course, this conveniently ignores the remote exploit in AIM which
AOL itself exploited to remotely upgrade users' AIM's whenever they
(AOL) upgraded the protocol (i.e. whenever someone else managed to
reverse engineer the protocol and bring out a compatible III-party
client :-)

3. Retrofitting security. It's is completely impossible to envisage
two scenarios when designing and developing software:

- - How it is going to be used
- - How it is going to be attacked

I'm a software writer from time to time, and all I can do as a
developer is *try* to ensure that the software and protocols I develop
are secure, to the best of my vision and ability. This problem is not
new: earlier it was said that it was impossible to make software
idiot-proof, since idiots are so smart; today I'd say that it is
impossible to make software and protocols crack-proof, since crackers
are too smart and varied.

Until it becomes possible to project in advance all possible scenarios
in which a software could be used we will never see a `secure' product
or environment. Instances of security being retrofitted in this sort
of situation abound: AUTH and STARTTLS extensions to SMTP, the
uncountable patches from software and OS vendors, HTTPS extentions to
HTTP, encryption extensions to IPv4, etc.

The depressing conclusion I come to is that it will become
increasingly difficult to lock down applications, protocols and
operating systems; we will just have to learn to live in insecure
environments.

Regards,

- -- Raju
- --
Raju Mathur raju@kandalaya.org http://kandalaya.org/
It is the mind that moves
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.6 and Gnu Privacy Guard <http://www.gnupg.org/>

iEYEARECAAYFAj0zfAQACgkQyWjQ78xo0X95+QCgl46cqfviPVDMoH55o96WDpWk
B1wAni0wxt/AMiiSI5Lva8HshIdc0QET
=Q7bh
-----END PGP SIGNATURE-----