Microsoft has reportedly begun investigating a potentially nasty denial of service vulnerability affecting Windows 7. A security bug in windows 7 and Windows 2008R2 makes it possible to lock up affected systems. The crash would happen without a Blue Screen of Death or other visible indication that anything was amiss. The system …
Yes far more stable! see, no BSOD!!
unable to shed extra light on the issue
Shed! as in; Windows is more stable?
The Nineties called...
They'd like their exploit back...
@ Geoff Mackenzie
I was thinking that, winnuke what fun :)
Caused by overcomplication?
Bet this wasn't helped by MS vastly overcomplicating the SMB protocol to try to keep out Samba
dear god, you've got to be kidding me?
MS don't need to try very hard to keep Samba on the backfoot. Just implement a protocol that was established after 1989, and watch the years roll by before Samba catches up.
"Whatever your firewall is set to"
"Whatever your firewall is set to, you can get remotely smashed via IE or even via some broadcasting nbns tricks, [with] no user interaction," Gaffié writes.
I presume he means the software firewall within Windows. I can't see my router letting through SMB messages from outside my network. Ergo, the attacker would have to be on my local network to do anything. I think I'll be fine...
New network files system
Come on, SMB was a crappy protocol when it was written twenty years ago. FTP is the worst protocol ever for the NAT age we live in. SSH doesn't integrate well with Windows. WebDAV looks like it would have been a great option, but the clients are, and have always been crap.
We are badly in need of a file transfer protocol that:
* Works over HTTP & NAT
* Supports compression
* Can randomly seek in the files
* Can transfer files in batch
* Allows remote differential compression
Actually, that pretty much sounds like WebDAV. How come no one supports it? Why am I always having to remember obscure IOS commands to setup FTP?
You must have been mis-informed. With their shiny new secure development lifecycle in place, it simply isn't conceivable that Microsoft could fail to check the sizes of incoming network packets. I mean, that would be a really basic error made right on the security front line, after two decades of embarrasing holes in this area, by the highly experienced kernel group, which also passed right under the noses of independent code reviewers (required by the SDL).
Unless of course, SMB is now so complex that no-one is able to review the code anymore, or the bug is actually a required feature of the protocol, for some reason that no-one can quite remember. (Note to Psymon, as I understand it, each released version of Windows actually implements a slightly different SMB protocol, none of which are documented. "Keeping Samba on the back foot" is pretty much Microsoft's whole business strategy on the server side of the PC business.)
Although the fix is far simpler than finding a way to exploit the vulnerability to execute arbitrary code, I fear that yet again the arbitrary code execution exploit will be doing the rounds before the patch.
laurent gaffie is a l33t blackhat.
ok how bout this one
so you use Anti-Pinning DNS attack to bypass firewall after you have identified a target with an office of windows 7 then use flash to send the broken packet to the broadcast then the loop-back and shut down the entire office...
social engineering is used to tweet to an employee during the day to allow for the DNS attack
would that work? would broadcast kill all the venerable computers? can flash send a "broken" packet?
Listen to the smart smug guys giggle and point. NetBIOS is NON routeable (without tunneling). So a vulnerable machine would have to be on the same subnet as an attacker or infected machine which was targeting this attack surface. Now, go ahead and try to telnet to a windows box (not in the same workgroup or domain) on port 137 and see what happens. This is FUD and fanbois are eating it up as usual. @Voodoo Trucker, yes, we need better protocols.
Some incorrect comments here.
First, to Annihilator, your ingress firewall rules do not matter. The victim machine makes the connection. If someone were to host a website with a hidden redirect to a server running Gaffie's code, the victim would attempt to connect to port 445 and crash. That said, if you have EGRESS filters on your router/firewall, meaning you don't let 445 OUTBOUND, then you are safe.
Second to Dustin 1, about Netbios being Non-routable. We are talking about SMB. I can be on any network in the world, and if you have a machine listening to 445, I can attempt a connection with dir \\ip-address\share and that will route to where the ip-address is (assuming it is public and not RFD-1918). As mentioned in my first comment, if you block 445 outbound, not an issue. If you are talking about NBNS broadcasts, then yes, those are not routable and must be on the same network.
There are two concerns with this whole thing. 1- How can MS let something so trivial as changing the assumed packet size in the header cause such a freeze. 2- This can become a DoS issue if people will ill-intensions start serving up this code on the internet then use phishing or hack known sites and add hidden redirects and send users to the code.
I tested the code on both Win7 and 2008 and it did indeed freeze with no trace of why.
actually all of the protocols that run on top of IP are routable - for example those TCP and UDP protocols that SMB uses (if you doubt TCP is routable, try loading "http://www.theregister.co.uk/" in your web browser) - try it, enable SMB on one computer (forward TCP port 445 if behind NAT) then from another connection load up \\x.x.x.x in explorer (replacing x.x.x.x with the IP Address of course), watch it load...
some ISPs do block specific ports for various reasons - however it's certainly not accurate to claim that SMB won't work over the internet, more accurate to claim that some ISPs block SMB traffic (it's certainly not common enough to assume an ISP does without checking)
of course the main story would be how this could be exploited on a typical windows 7 setup with its software firewall enabled sitting behind a NAT
Really? TCP/IP is routeable?........ anyway, I was looking at this line from the article: "specifically a NetBIOS (Network Basic Input/Output System) header that specifies an incoming SMB packet "
now see this simple definition of a non routeable protocol:
In order for NetBIOS to be routeable, NetBEUI has to be running on top.
Now, from the praetorianprefect.com areticle, notice this line: "What is the big deal?
To simulate how an attacker could use this, we hosted a small INTERNAL web page
Now, is this technique useable over the interwebs? I can't easily test that theory.
Why am I not surprised ?????
windows 7 busted after being released for how many days ???
did it really take that long......
Because even Paris could probably do a better job of os security ( better than micro$haft )
This all sounds so very familiar.
Re: Dustin 1
As a web developer who works from foreign countries, promoting always pisses me off, so I've started investigating WebDAV in earnest. It looks like a great protocol, its just that all the clients suck!
I've started work on a client. If it goes anywhere, I'll post it to source forge. It should support the features I stated above, probably excluding remote differential compression.
IIS seems like a great server. The only thing I am missing is an MD5 (or other) hash of the content. It has all the other features built in. It sucks to configure though, since it enables a crap load of ISAPI filters by default, and won't serve up files it thinks are sensitive, (App_Data, etc).
VoodooTrucker - those specs
would be fairly close to a P2P system?
mines the one with chuddy in the pocket.
Back in 1984
Reminds me of 1984, when a bunch of "motivated young men" ;) did experiment with the behaviour of the then -claimed- unhackable BTX system in Germany. Around 125000 Deutschmarks later the German Post -as the BTXs operator- had to remove said "unhackable" claim.
Interestingly, said experiment did include sending slightly larger answers back to the BTX system than BTX expected.
One would expect input sanitation had become common within the past 25 years...
These men were later known as the CCC, btw.
still crappy SMB
Back in the late '90's I found that SMB packets that were padded to an even (double)word-length contained bytes from the previously transmitted packet as the padding. I'm not sure if it was a problem with SMB or with the NIC drivers (Intel).
I think you'll find that MS try *very* hard to try to keep out Samba - there is a podcast somewhere where an ex-MS employee admits that MS wanted to 'f*** with Samba'
The SMB protocol was changed so that instead instead of there being about 4-6 messages to delete a file it took about 160 - of course, Tridge reverse engineered it - but over-complicating things leads to security holes. (As if MS give a f*** about that of course!)
@WebDav people looking for a client
It's built into Windows BTW, but if you have Office 2003 installed it screws it up - There is, as always, a patch workaround.
Google is your friend.
I use it all the time, it does kick FTP's arse big time
Re: Mike Lovell
The OLE client blows balls (isn't a real file system object), and the XP mini-redirector doesn't work with https (from what I understand). I've tried bitconnex and the total commander plug-in. Even in Vista/Win7 which apparently do support https, they are crap at copying large amounts of files, because if one fails, then the whole copy aborts.
Don't get me wrong. If your using it and happy with it, then go with it. Myself, I'd like something more like FileZilla but with WebDAV.
Beer, because I'm off to the pub.
In case anyone still cares...
I've got a decent little WebDAV client going. It seems to about double SMB performance over VPN. A typical web promotion of 4.5MB in 150 files took about 50 seconds in Windows explorer (sometimes several minutes in Vista/7). I've got my multi-threaded WebDAV client doing it in about 25 seconds.
I'm looking into other bits like disabling ASP.NET on IIS, cutting out some HTTP headers, and intelligently reusing HTTP connections to see if I can gain any more speed. Already though the implications of not having to do any special configuration of a firewall will be great.
I'll stay with ArchLinux.