Mailing List Archive

I think I just saw a pig fly, hell freeze over etc...

I actually agree with Paul Schmehl on something other than Russ Cooper is
a sexy beast (not).

Mindless "dont use windows reccomendations" are just that, mindless. If
you poorly manage the security of Windows networks what makes you think
that you will manage the security of *nix networks any better?

I do Pen-Tests for a living -- there are just as many ways to own a *nix
box as there are a windows box.

Do you expect that the mindless user base is going to be able to figure
out Linux (even with X) when they can barely run their MS based machines?

So many of my clients would fire you on the spot for reccomending that
they just stop running MS products. If you truly are a security
professional -- you would know better.

NOTE: I am not saying that MS products are superior in any way - for
those that know what they are doing - yeah run your favourite *nix.

On Sun, 14 Jul 2002, Paul Schmehl wrote:

> Date: Sun, 14 Jul 2002 22:24:51 -0500 (CDT)
> From: Paul Schmehl <pauls@utdallas.edu>
> Reply-To: full-disclosure@lists.netsys.com
> To: full-disclosure@lists.netsys.com
> Subject: Re: [Full-Disclosure] Counseling not to use Windows (was Re:
> Anonymous surfing my ass\!)
>
> Do you then wash your hands of that client? Or do you purport to provide them with security expertise without helping them secure their network, simply because you're opposed to the use of MS products? Companies make stupid decisions all the time. It's the job of security professionals to find a way to make that nework _as_secure_as_possible_ regardless of the applications they have chosen to use.
>
> IOW, after you've gotten off your evangelist's pulpit and come down into the real world, do you simply walk away from clients that refuse to take your advice? Or do you help them secure their network _despite_ their poor choices?
>
> Paul Schmehl pauls@utdallas.edu
> Supervisor, Support Services
> University of Texas at Dallas
> AVIEN Founding Member
>
> ----- Original Message -----
> From: "David F. Skoll" <dfs@roaringpenguin.com>
> To: <full-disclosure@lists.netsys.com>
> Sent: Sunday, July 14, 2002 4:58 PM
> Subject: [Full-Disclosure] Counseling not to use Windows (was Re: Anonymous surfing my ass!)
> >
> > I think it's important for security professionals to tell people not
> > to use Windows, if only to open their eyes to the risk they put
> > themselves at, and also to the fact that there are alternatives out
> > there.
> _______________________________________________
> Full-Disclosure - We believe in it.
> Full-Disclosure@lists.netsys.com
> http://lists.netsys.com/mailman/listinfo/full-disclosure
>

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

"I don't intend to offend, I offend with my intent"

hellNbak@nmrc.org
http://www.nmrc.org/~hellnbak

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

On Sun, 14 Jul 2002, Paul Schmehl wrote:

> Do you then wash your hands of that client?

It depends. I state up front that I do not support Windows, period.
If they want me to install and configure Linux boxes as file servers
or mail servers, I work for them. If they want me to do Windows work,
I decline.

> IOW, after you've gotten off your evangelist's pulpit and come down
> into the real world, do you simply walk away from clients that refuse
> to take your advice?

Again, it depends on the situation. Sometimes, yes. If clients go
completely against my advice, they're not worth having. It will blow
up in my face later.

--
David.

On Mon, 15 Jul 2002, hellNbak wrote:

> So many of my clients would fire you on the spot for reccomending that
> they just stop running MS products.

Fine; that's their choice.

> If you truly are a security
> professional -- you would know better.

I think this is a very bad attitude. Trying to secure Windows on the
desktop is fundamentally impossible because of design flaws.

Sure, UNIX boxes can be owned, no question about it. They can be
owned because of bugs such as buffer overflows, tempfile races, etc.
which are implementation problems.

Windows boxes are fundamentally insecure because of bad design, not only
because of programming errors. Encoding metadata such as "executableness"
in a filename, for example, is a fundamental design flaw, and one that's
impossible to correct without changing Windows' design.

So no, I don't refuse to deal with clients who use Outlook. But yes,
I recommend they switch anyway, because to do less is an abdication
of my responsibility.

--
David.

> because of programming errors. Encoding metadata such as "executableness"
> in a filename, for example, is a fundamental design flaw, and one that's
> impossible to correct without changing Windows' design.

Sorry to pick on your example but an extension merly indicates what kind of
data is in the file. A .txt extension suggests that a user might want to
hand the file to a program that'll treat the file as plain ASCII, similarly
an .exe extension suggests that a user might want to give the file some
memory and time slices and treat it as a program in it's own right. You
could load the .exe into notepad, and you could execute the .txt file.

As for the actual security of whether a user /can/ execute a file, Windows
doesn't seperate 'read' and 'execute' privileges well enough. However it's
my understanding that's got more to do with the design of the x86 memory
architecture than Windows' design. Linux just pretends to seperate 'r' and
'x' privs because it's a unix clone. I'm prepared to stand corrected on that
though.

I agree completly that Windows does have some fundamental design flaws that
prevent it being locally secure. A better example might be the ability of an
application to send messages to another application, apparently without
regard for who the owner of the target application is.

- Blazde

On Mon, 15 Jul 2002, Roland Postle wrote:

> > because of programming errors. Encoding metadata such as "executableness"
> > in a filename, for example, is a fundamental design flaw, and one that's
> > impossible to correct without changing Windows' design.

> Sorry to pick on your example but an extension merly indicates what kind of
> data is in the file.

Not under Windows as it is configured by 99.99% of end-users. If you
name a file "foo.txt", very different things happen if you click on the
file than if you click on the exact same file named "foo.exe".

> A .txt extension suggests that a user might want to
> hand the file to a program that'll treat the file as plain ASCII, similarly
> an .exe extension suggests that a user might want to give the file some
> memory and time slices and treat it as a program in it's own right. You
> could load the .exe into notepad, and you could execute the .txt file.

Again, for 99.99% of end users, such fine points are irrelevant. To them,
clicking on an .exe runs the program. Windows even "helpfully" hides the
extension by default.

> As for the actual security of whether a user /can/ execute a file, Windows
> doesn't seperate 'read' and 'execute' privileges well enough. However it's
> my understanding that's got more to do with the design of the x86 memory
> architecture than Windows' design. Linux just pretends to seperate 'r' and
> 'x' privs because it's a unix clone. I'm prepared to stand corrected on that
> though.

That is true when it comes to memory protection, but what you're
talking about is filesystem protection, and Linux doesn't "pretend"
anything -- it enforces it. I believe it is possible under some
versions of Windows to allow read access but not execute access to
files and directories, but again, 99% of end-users don't know this
and don't configure it.

> I agree completly that Windows does have some fundamental design flaws that
> prevent it being locally secure. A better example might be the ability of an
> application to send messages to another application, apparently without
> regard for who the owner of the target application is.

:-) I'm not familiar enough with Windows to be aware of things like that.
Thanks.

Regards,

David.

I should mention that I'm only referring to Windows NT here, Windows 9x /is/
one monumental design flaw and not even worth talking about.

> That is true when it comes to memory protection, but what you're
> talking about is filesystem protection, and Linux doesn't "pretend"
> anything -- it enforces it. I believe it is possible under some
> versions of Windows to allow read access but not execute access to
> files and directories, but again, 99% of end-users don't know this
> and don't configure it.

It's hardly a 'fundamental design flaw' if it can be configured differently.
Many default unix installations will leave all a user's newly created files
with world read access. And I bet the vast majority of novice computer users
(the ones most at risk) would find it easier to change their file
permissions on a Windows machine than a unix machine.

The fact that 99% of Windows users are clueless is no reflection on Windows'
actual security.

- Blazde

>
> The fact that 99% of Windows users are clueless is no
> reflection on Windows' actual security.
>

I agree. I have some very large clients with thousands of workstations
and thousands of servers and there is no way in hell that they will
change all their workstations from Win2K to a *NIX distro based on some
security scare tactics and FUD. Sure, new servers being put in,
depending on their use and the IT departments exerptise can be *NIX
based and many are.

Yet, with my help, they have had clueless users open malicious emails
and have the attached worm fail -- why? Because each and every
workstation is locked down appropriately and still functions fully.
Yeah it's a lot of work, but it can be done.

Making the general statement to not use Windows shows nothing but
ignorance of the configuration options available. Granted, if an
organization was using nothing but Win98 then yes, I would say to them
that they need to upgrade, but they can upgrade to a Windows O/S if they
want. Hey if you don't know Windows just say so, we aren't going to
laugh at you because you have the ability to understand *nix but not the
easy point and crash Windows. :-) heh

On Mon, 15 Jul 2002, Roland Postle wrote:

> I should mention that I'm only referring to Windows NT here, Windows 9x /is/
> one monumental design flaw and not even worth talking about.

> It's hardly a 'fundamental design flaw' if it can be configured differently.

Well, OK. But let's say you tighten up security on NT. Then you
discover that all kinds of third-party (and Microsoft, for that
matter) software doesn't work any more.

> Many default unix installations will leave all a user's newly created files
> with world read access.

That's true. World-read access is slightly less of a problem than
world-execute access. And some Linux distros (e.g. Mandrake) offer
"security levels" which (among other things) let you change the default
umask to 077.

> And I bet the vast majority of novice computer users
> (the ones most at risk) would find it easier to change their file
> permissions on a Windows machine than a unix machine.

Well, the vast majority of novice computer users aren't using UNIX
(unless you count Mac OS X).

> The fact that 99% of Windows users are clueless is no reflection on Windows'
> actual security.

But Microsoft touts "ease of use" which lulls people into believing that
you don't need as much skill to use or secure Windows as UNIX. And that's
irresponsible.

--
David.

>
> Well, OK. But let's say you tighten up security on NT. Then
> you discover that all kinds of third-party (and Microsoft, for that
> matter) software doesn't work any more.

Been there done that. You put yourself in a lab with test boxes, lock
the machine down then slowly relax things until all the apps work.
Then, when new custom apps are being developed, they get developed on
the locked down platform and with good developers, this can work.
Granted, a lot of organizations have problems with this but that why I
get paid. :-)

> But Microsoft touts "ease of use" which lulls people into
> believing that you don't need as much skill to use or secure
> Windows as UNIX. And that's irresponsible.

I agree. MS has always put usability <sp?> over security. Hopefully
things will change but I'm not holding my breath.

> > The fact that 99% of Windows users are clueless is no reflection on
Windows'
> > actual security.
>
> But Microsoft touts "ease of use" which lulls people into believing that
> you don't need as much skill to use or secure Windows as UNIX. And that's
> irresponsible.

I perhaps should have said it's no reflection on Windows' security relative
to unix. It is of course Microsoft's responsibility to make Windows more
secure for the average clueless user, especially given that their
advertising campaigns are so obviously directed at the clueless user.

> 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.

Agreed complexity is the enemy of security, but unix file permissions are
nothing but an unfortunate relic of the past. Owner and world permissions
are a good start, and very useful. Group permissions are just a glance in
the direction of a proper ACL. If a user wants to give access to another
user to a file can they? Not unless those two users happen to be by
themselves in the same group. The user has to give all other users in the
same group (or worse, everybody, if they happen to be in different groups)
access to the file.

Then we come to the suid/sgid bits. What are they really about? It took me
over a year of using unix to figure it out. If this file is executed it runs
in the security context of it's owner and/or group. Is that a permission? It
certainly isn't a permission that refers to a user. It refers to something
the file can do, and that's very different from whether a user can
read/write/execute it or whatever. The idea is to create 'program domains'
(what a program can do or can't do, as opposed to what a user can do or
can't do), but the fact that they're implemented as user domains is another
fudge. And an extremely confusing one at that, because many unix programmers
don't fully understand the distinction.

Windows is no less confusing, but as Paul pointed out, it is at least
functional.

- Blazde

On Mon, 15 Jul 2002, Roland Postle wrote:

> Agreed complexity is the enemy of security, but unix file permissions are
> nothing but an unfortunate relic of the past.

Not arguing with that. UGO are simple, but not very flexible. They
can be made to work well in most situations, though, especially if you
use the modern setup whereby each user has his own group, and then you make
additional groups for projects.

> Then we come to the suid/sgid bits. What are they really about? It took me
> over a year of using unix to figure it out. If this file is executed it runs
> in the security context of it's owner and/or group. Is that a permission?

Nope. It's a "file mode".

> The idea is to create 'program domains'
> (what a program can do or can't do, as opposed to what a user can do or
> can't do), but the fact that they're implemented as user domains is another
> fudge. And an extremely confusing one at that, because many unix programmers
> don't fully understand the distinction.

Actually, I find suid/sgid very easy to understand. They can be explained
in a single sentence. And implementing program domains as user domains
is necessary in UNIX because of the design. It might not be a pretty design,
but it works, and (more importantly) doesn't have any fundamental security
problems.

For very security-sensitive applications, this might not be good enough.
enough. NSA's SELinux has proper program domains and very fine-grained
control over what each program can do. Internally to the Linux kernel,
there are finer-grained "capabilities", but there's no agreement on
how to map these to the file system.

> Windows is no less confusing, but as Paul pointed out, it is at least
> functional.

Aw, come on. :-) The UNIX model is pretty functional too.

--
David.