Slashdot Mirror
Looking Back At Windows Security In 2003
thebatlab writes "Help Net Security has an interesting look at security in Windows during 2003, with various blurbs from related parties at Microsoft as well as security 'bigwigs' such as Russ Cooper. It's interesting to read the comments from external parties, as they tend to be very reasoned comments and don't simply attack away over recent 'indiscretions' and 'security lapses' Microsoft has had over the year."
"What Slammer showed us more than anything was the need to embrace more basic controls, such as "Default Deny"."
Do you think that that giving your user name and password to strangers might be a bit suspect too?
I'm sorry, but we've been told to disable preview-pane at work because yet another round of virii struck that used our internal servers as spam relays.
For Outlook issues alone (forget about slammer - though how could you!) Microsoft earns the big security rasberry of the year. PPHbth!!!
"There is more worth loving than we have strength to love." - Brian Jay Stanley
2004 will likely prove to be just as wormy as 2003.
I also predict that Linux will truely come into its own in 2004 as the first serious Linux worm/virus rock the open source world.
it says: The site www.net-security.org is running Apache/1.3.28 (Unix) PHP/4.3.3 on Linux.
Windows 9x was never intended to be secure... it's a wide-open home user OS... don't feel like logging on? Just hit the cancel button at the logon screen.
If you're going to discuss Windows security, for god's sake at least do it with a version of Windows designed to be at least somewhat secure (2003, XP, 2000, or even NT).
It basically says it all when an exploit that had been patched for months succeeds in bringing the internet to a crawl.
Well as for apt-get or yum you cant compare those to windows update at all. First of all apt-get/yum updates every single application installed while windowsupdate doesnt even update Microsofts own products outside IE or MS-Windows. Had it covered atleast MS own products but it really is limited. Tried running windowsupdate from a script? Apt-get/yum is way ahead of windowsupdate in any way i can think of. And it doesnt cost you more than hardware to put your own apt repository up.
Why would anyone need exchange? Did you want a mail server or did you want Exchange in specific? You do realize that what you are saying is that you want the brand and not the function in itself? There are tons of ways to accomplish the same things Exchange does and most often much better and with cheaper hardware. If its one thing exchange does it is eating cpu cycles.
"For firewall we kept windows because the software we currently use performs much better on windows than Linux"
Well, duh? Sygate runs pretty lousy on linux too.
HTTP/1.1 400
apt-get upgrade
Need I say more?
I want my Cowboyneal
I buy a packaged consumer product and install it on my computer.
Why should I be expected to know there is such a thing as a firewall and that I should install it?
To put it simply, that's unrealistic. Sure, geeks should know better, but the general public shouldn't have to.
Period.
D
I just hope that in the next few weeks we won't see a disaster like the Slammer worm.
That, in a nutshell, destroys the entire article. The end user shouldn't be forced to "hope" that bad things won't happen to their computers. Any vendor that instills so much lack of confidence in their products doesn't deserve the benefit of the doubt.
If you're going to discuss Windows security, for god's sake at least do it with a version of Windows designed to be at least somewhat secure
You're missing the point.
The more secure Microsoft Windows is the old unpatched "insecure" Windows.
That says something about how effective Microsoft has (NOT) been with its security endeavors.
I do not see any security. As Gates/Balmer have said "it would be far too expensive to fix Windows" Besides by fixing Windows, the forced $upgrade$ incentive would go away. The problem with the MS software model is that if you make it too good no one will upgrade. Like banks and OS2, IBM focused on getting the security right, look what happened!
OH THE SHAME I fell off the wagon and use sigs again!
Microsoft puts itself in a catch-22 with this one.
Microsoft released a patch, yes. There are two people who wouldn't install it: those who don't have a clue about being a sysadmin (MCSE) and those who know MS's history of distributing broken patches.
The first group (mostly made of MCSE-only admins) are either too ignorant to install patches timely or are too stupid to know that your SQL server has no need to be internet-accesible. IIRC the only way to get slammer was to have your unpatched SQL server live to the world, something that anyone even slightly security concious wouldn't have done. Unfortunately, MS markets themselves as the easy delpoyment/any idiot can admin. So, they market themselves to idiots, then blame the idiots for not taking care of their servers. Umm... sure.
Secondly is the smart group who knows better than to deploy ANY MS patch without testing it. Having a patch 2 months before the worm hits is fine and good, but often times testing a patch takes that long. In the case of slammer these are the guys who know to keep their SQL servers behind the firewall. Slammer was mostly due to group #1. In the case of IIS and other internet services, however, a patch may not be deployed in a timely manner.
Combine MS's past of releasing broken patches with their careful marketing to idiots and you see how easily this crap happens.
There is no reasonable defense against an idiot with an agenda
:wq
Maybe so, but you haven't mentioned any.
The quality of your admins has way more to do with ultimate security.
Can't argue with that.
Agreed that NT has access controls on every object. However they are not visible and not used very much by end users and administrators.
Much like *properly* setup sudoers, groups and file ownerships/permissions.
The UNIX ones are simple and very easy to understand.
That's because they're so primitive. Not to mention some of them aren't really logical - like needing read *and* execute permissions to list the contents of a directory.
Here you have the choice between complicated (you do know the difference between discretionary and inherited rights filters?) and pervasive (every object) versus simple and pretty much only on files (which almost every OS object is anyway).
Properly setting up a combination of sudo, groups and file permissions and ownerships is a monumental task and an administrative nightmare. Not saying ACLs are a walk in the park, but when you're finished with sudo & co you've got an ugly hack around a fundamentally broken design, when you're finished with ACLs you've got an elegant and maintainable solution.
The Windows acceditation is a crock. It is in a non-networked environment with no floppy disk or CD drive.
That's because, IIRC, being without a network and floppy drive were *requirements* of the accreditation - IOW, *no accredited OS* could have had them.
(And we won't even go into the ability of any process in a desktop session being able to send messages to any other process which is probably the flaw Microsoft alludes to).
This was fairly well rebutted at the time - applications can be written so that this can't occur.
In Linux you have to understand chmod.
This is ridiculously (and irresponsibly) oversimplified. You have to understand group participations, file ownerships, permissions, SUID, GID, sticky permissions and the subtly different ways some file permissions can act on different platforms. This is before worrying about things like limitations on how many groups a user can be in and other weird things that only happen on some platforms. Not to mention the inescapable fact that on most unixes, practically all important services and administrative tasks have to spend some time with the unlimited priviliges of UID 0.
I better idea is not put unnecessary windows or doors, locked or unlocked. Although linux generally does this well, I can't speak for all distributions of linux.
Windows should do things like many linux services do. They default to listening on localhost only, a lot of little things like that could help tighten windows a little better.
Understanding is a three-edged sword. -- Kosh Naranek
Let me ask you this: how can you restrict privileges to the RPCSS service?
Well?
I'm still waiting for an answer.
The answer is that you cannot restrict privileges to the RPCSS service. It must run as SYSTEM, the NT equivalent of root. Although ACLs can be applied to the SYSTEM account, they can be bypassed easily as SYSTEM can insert code to run at IA32 ring zero.
Let us then see how many services run by default under the SYSTEM account in a Windows machine: well, that's all of them, isn't it?
Why don't we try a little experiment. Lets take a ridiculously trivial service, one that can be written in minutes: the Messenger service.
Now let's take Messenger and run it under a different account so we can apply access controls to it. What does it do?
Well, now what does this mean? Perhaps I did not give the Messenger service a privileged enough account? Nope. Perhaps I need to restart the computer rather than starting the service directly? Nope.
The problem is that Messenger runs as a thread under svchost.exe, as it is an RPC service "built into" the various other crap there. Is this a fine-grained security model?
Note also that when you attempt to have a service start under different credentials (should you ever attempt this as I very seldom see it), you must type the account's password. Perhaps this is a security feature so that one cannot install a service which then grants the user elevated privileges? Nope.
In order to change credentials in NT ("obtain a security token"), you must supply the account's password. When you have a service run under a different account, that password that you type in is saved somewhere as it must be supplied in order to obtain different credentials. Where is it saved? Beats me. How is it stored? Probably "encrypted" using some machine-specific information; however, it must be decrypted upon launch of the service, so the password must be recoverable (without undue computation, eg, it is not hashed).
Linux system administrators must spend huge amounts of time understanding the latest Linux bugs and determining what to do about them.
...
Configuring Linux security requires an administrator to be an expert in the intricacies of the operating system and how components interact.
Again, let me pose a question to you, as I assume you see yourself as a competent NT administrator:
How do you disable DCOM without restricting RPC? You cannot consult google, but must discover the answer on your own.
Obvious response: firewall.
Well, a firewall isn't the answer. Say box X needs to talk to box Y using DCE RPC. You cannot insert any firewall I know of between X and Y which stops DCOM but allows through other RPC programs as no firewall I know of works at this level of the stack. You could perhaps put something like a snort box in between X and Y that allows for user-programmable packet inspection, but please don't tell me that's "easy to set up and administer".
Correct response is documented here. But a competent NT administrator such as you knew that, of course.
Let's tackle the equivalent problem on a Unix machine: we have an RPC service that we want to disable. Well, which one do we want to disable? NFS? Stop nfsd from launching. YP? Stop ypbind from launching. Mountd? Stop mountd from launching. You get the idea.
How do you stop a daemon from launching? Tru
Why does the link to your Linux section of Security Tracker point to: "View Topics > Underlyingos > Windows (Any)" ?? Looks to me like you pointed to Windows (ANY), not Linux.
Likewise, I compared Windows XP to FreeBSD. Windows XP had 3039 documents of security problems, and FreeBSD had 404.
The day Microsoft creates a product that doesn't suck, it will be known as the Microsoft Vaccuum Cleaner!