Microsoft States Full TCP/IP Too Dangerous

daria42 writes "To fully implement the TCP/IP protocol in Windows XP would make creating denial of service attacks 'entirely too trivial', Microsoft has claimed. The company was responding to claims by Nmap author and well-known security expert Fyodor that by repeatedly disabling the ability to send TCP/IP packets via the 'raw sockets' avenue, Microsoft was asking the security community to 'pick their poison': either cripple their operating system or leave it open to hackers. Admitting that a recent security patch had intentionally disabled a community-developed workaround to Microsoft's TCP/IP changes - which were first implemented in Windows XP Service Pack 2 - the company claimed it had received little negative feedback on the issue."

Baby, meet bathwater.

[mfh]

To fully implement the TCP/IP protocol in Windows XP would make creating denial of service attacks 'entirely too trivial'

This is because XP is not designed right, not because the TCP/IP protocol is wrong. (just to be clear)

The quote [seclists.org] from Fyodor is:
"Pick your poison: Install MS05-019 and cripple your OS, or ignore the hotfix and remain vulnerable to remote code execution and DoS."

It's like... we just... can't... win.

Fyodor goes on to say...

"Nmap has not supported dialup nor any other non-ethernet connections
on Windows since this silly limitation was added. The new TCP
connection limit also substantially degrades connect() scan. Nmap
users should avoid thinking that all platforms are supported equally.
If you have any choice, run Nmap on Linux, Mac OS X, Open/FreeBSD, or
Solaris rather than Windows. Nmap will run faster and more reliably.
Or you can try convincing MS to fix their TCP stack. Good luck with
that."

The answer, my friend, is to drop Microsoft.

Baby, meet bathwater.

I remember...

[Karpe]

Steve Gibson's crusade [grc.com] againts Windows raw socket capabilities. Did Microsoft listen, and now is being criticised for doing that?

Re:A wise decision

[TheRaven64]

On UNIX-like systems, creating a RAW socket can only be done by the superuser. Putting a similar restriction on Windows (substitute Administrator for superuser) would provide no benefit, since Windows is designed in such a way that most users run as an Administrator. Depressingly, the RunAs service has been around for many years now, completely eliminating the need to run as an Administrator. Unfortunately, the lack of a decent UI for this service has prevented its widespread use.

Re:A wise decision

[Karzz1]

the RunAs service has been around for many years now, completely eliminating the need to run as an Administrator

You must be kidding. The runas service is *nothing* compared to a true multi-user environment. Other than installing software runas is useless. How do you modify the registry without logging out the local user? How do you add printers to the machine without logging out the user?

Runas is a hack to make up for oversights in the OS.

Re:Ulterior motives

[0x461FAB0BD7D2]

If they locked down raw sockets and made it available only to administrators or root users, that would solve it.

Gibson points out that other operating systems do this, while Windows doesn't. The problem lies there, not in the inclusion of raw sockets API.

Re:A wise decision

[Chibi Merrow]

How do you modify the registry without logging out the local user?

runas /user:Administrator@domain regedit.exe

How do you add printers to the machine without logging out the user?

runas /user:Administrator@domain "C:\program files\internet explorer\iexplore.exe"
Click View, Explorer Bar, go to printers control panel, add printer...

Yes, you're right, there are some things you still can't do using runas, but not many. Be creative.

Re:Baby, meet bathwater.

[Krach42]

After walking throught he MS articles and stuff, I came across this: http://support.microsoft.com/kb/897656/ [microsoft.com]

Quoted from there is basically. If you want to use hand-crafted TCP/UDP packets over a raw IP connection, you must enable the Internet Connection Firewall.

At least, this is for SP1, I don't know if you can get away with this in SP2.

Steve "Ahab" Gibson

[Anonymous Coward]

Since you link to Steve Gibson Research, I'll have to link to grcsucks [grcsucks.com]. His (Steve's) views were wrong then, and they're still wrong today. The "raw socket == ddos" argument was thoroughly discredited:

Dissecting Steve Gibson GRC DoS Page [grcsucks.com]
Raw Sockets are not a Security Risk [grcsucks.com]

Bloody, I know about too many old flamewars.

Re:So when...

[Lunix Torvalds]

Hi,

With Windows sockets, it is imperative to look at the error returned by send() if it fails. If the error is WSAENOBUFS, then it means that the packet you are trying to send is too large and must therefore be reduced. It is possible that the Java implementation doesn't do this.

Here is a snippet of code that is NECESSARY to be able to transfer data reliably on Windows. Please note that while just a single send() will work most of the time, there is no garantee that it will. Try, for example, sending chunks of 1MB, 8MB, 64MB, 128MB and 256MB and see at what point you get WSAENOBUFS. You may be surprised.

while (cbBuffer > 0)
{
for (cbToSend = cbBuffer;;)
{
cbSent = send(Socket,Buffer,cbToSend,0);
if (cbSent >= 0)
{
Buffer += cbSent;
cbBuffer -= cbSent;
break;
}
else if ((WSAGetLastError() != WSAENOBUFS) || ((cbToSend >>= 1) == 0)) return FALSE;
}
}

Note that on UNIX you should check errno for ENOBUFS as well, just in case.

Oh my god, this has been debated since 2000

[presroi]

I remember "Steve Gibson" was bashed and debunked for talking about raw sockets in 2000 or 2001.

There is a short audio file from Rob Rosenberg from where he repeadingly laughs at his claims.

By the way, wasn't Gibsons site defaced today by Fluffy Bunny?

http://www.farook.org/arc20010701.htm [farook.org]

http://www.vmyths.com/rant.cfm?id=335&page=4 [vmyths.com]

http://www.theregister.co.uk/2001/06/12/security_g eek_developing_winxp_raw/ [theregister.co.uk]

and so on. Is there anything new that has happened in the last 4 years?

Re:A wise decision

[Anonymous Coward]

It's similar, but not equal, to "sudo", not "su".

"su" (or better yet "su -") gives you a root session you can reuse as long as you like.

"sudo" launches only a single command from the CLI

The real difference is that the CLI in *nix like OS' (especially linux) is far more powerful and with less effort.

Sure, you can do almost anything from the CLI even in windows... but where is the documentation about it? Where are the "manpage" equivalents? CLI usage in windows is really obscure stuff.

Often you have to install additional tools to get full functionality (adduser, anyone?)

Besides, the installed programs are NEVER in the system path (since windows does not have a central repository for executables), so the CLI becomes even less useful. Or more cumbersome: "start c:\program files\ahead\nero\nero.exe " is a tad long, opposed to, sah "k3b "

Re:MS innovates counter arguments shock!!

[sqlrob]

As long as the account has "Load Driver" privilege, you don't need to reboot to install kernel level code. Unloading it takes a reboot though...

It's also not "vastly more complicated", it's a different interface and *gasp* requires correct code to not blue screen.

Re:So when...

[PurpleXanathar]

Because XPSP2 recv Buffers are limited to 8KB.
Every OS has a size for those buffers, you have just discovered the XPSP2 size, congratulations.

Every other OS has a limit on that buffer, and I guess for every OS it is configurable in some way (in Windows there is some remote key in the registry).

Re:Responding to Steve Gibson

[Lothsahn]

Technically, you are right... But Gibson's claim is that by not providing easy access to raw sockets, it becomes much harder to engineer viruses or other malware to produce successful attacks. He never claims it's impossible--in fact, he claims that the user can reimplement raw socket support--but reimplementing raw sockets is significantly more difficult than using an existing API. And considering that a large majority of viruses and malware is due to 5cr1p7 k1dd135, and not real hackers, this helps. Remember, this doesn't make Windows secure, it's just one step to make it less harmful... and that's Gibson's claim. It's one piece of the puzzle (that's mostly empty at this point).

Re:A wise decision

[mordejai]

RunAs doesn't always work as expected
But this guy [msdn.com] has a blog dedicated completely to the whole non-admin subject, including some utilities to make it easier.

Re:Baby, meet bathwater.

[Anonymous Coward]

The firewall does one thing for outbound:
blocks packets that have a source address that is not valid for the host. This blocks the problem with spoofed source addresses Steve Gibson was talking about.

really?

[bmajik]

there's nothing to suggest that Linus et al would be able to improve the security of windows while ensuring that it meets its requirements. Linus has enough problem with is own operating system (but can conveniently choose to say all of userland isn't his fault when thats where the vulns are)

In any case, it's funny that you chose linux - arguably the least secure of the modern unixes. I'd have entertained a suggestion of Theo, but he'd fail because im sure his approach would be "the requirements don't matter, this is how i think it should be done", and then half of the crap customers expect would be broken.

I'm not sure how you read my statement about raw socket support being a bad thing for home users, but the point i was making is that they're not using it, so it doesn't help them, and because of the other factors i outlined, it makes thier machines more attractive and more potent for botnet membership.

If its not helping them, and its a risk, then removing it is a good thing, right ?

I don't understand some of your accusations as "bullshit". Are you telling me i'm lying to you? Do you have informatoin that I don't?

I remember the announcement internally that XP home would run with users= admin and being irate about it. Lot's of us were hoping that we'd get it right for xp but the people upstairs couldn't stomach the amount of appcompat breakage it would cause. As it is the amount of custom code in the various versions of windows for 3rd party app support is pretty outlandish. Read raymond chen's blog for a glmipse of what he was doing back in the windows 95 days to help appcompat. Things like this matter when you have 1) an installed base 2) a bunch of 3rd parties making money off your platform 3) binary compat as a requirement. Note that linux has none of these 3 aggrivating factors to deal with. (not anywhere within an order of magnitude of where MS is, at least)

For what it's worth, I agree that our testing, design, and management are all inadequate. We're just human. As an aside, we're hiring. Are you qualified to help, or just to bitch?

Get Ready for... MS TCP/IP!!

[skeptictank]

We all knew it was coming, I am surprised it took them this long to get around to it.

Linux is looking better and better everyday, even to our management.

Re:Privileges anyone?

[Foolhardy]

I find the problem to be the insidious architecture of XP specifically the lack of clear demarcation between a priveleged user and an admin.

Power Users is kinda in the middle. I guess the idea is that you can assign permissions and privileges to users as needed.

And I pretty much always have myself configured as an admin type user... not because I have to all the time (I do lots of work not needing that level of access) but more because of the unpredictability of what isn't going to work in some strange way when I'm using XP as an un-priveleged user. It sucks, but I've found it to be the most expedient way, and I'm always nervous about it.

Yeah, I usually end up doing the same thing too, for the same reasons. There are way too many apps that are somewhat broken, fail to start silently or otherwise balk at getting only reasonable access to the system. To mitigate this, I logon, run the shell and trusted apps as an admin, but start everything else with restricted tokens [microsoft.com] with the administrator's group SID and often the user identity SID deleted. Also, I usually make jobs [microsoft.com] for them which restrict USER handles and some reasonable memory and process quotas. These are really useful security features that have been available since Windows 2000, but as usual Microsoft provides no easy way to exploit them. I wrote a little command-line program that exposes most of the features of job objects and restricted tokens, jobprc [comcast.net].
For example, I can run jobprc iexplore -dsid administrators -dprivmax -handles -prclimit 20 -jobmem 64000000 and be assured that a vuln in IE could damage my own profile or stuff that everyone has access to at most (since it still has my user SID enabled). Denying access to my profile breaks tons of apps (they get read-only access to the default user profile instead). Restricting SIDs are very powerful, (closer to a capabilities style system) but tend to break things in all kinds of weird ways.
Anyways, the underlying system is there, but 1. it's hard to get to and use and 2. it's popular to ignore.

Everything pretty much works the way it's supposed to in a unix world -- the unix community is pretty savvy about what the various directory structures are for, what levels of access they provide, and how to work within that paradigm.

Yeah, espescially UNIX developers vs Windows developers. I find that cross platform or UNIX software ported to Windows is the best behaved.
Plus, the biggest problem with the NT security model is that it's too complicated for most developers (let alone most users) to bother with. Good old rwx permissions on files are very simple by comparison. An operating system for The People should use something at least as simple.