Microsoft Windows SMB Tree Connect Response memory corruption vulnerability

[Questargon]

The CERT found a memory corruption bug in the Windows SMB Services (used for network sharing, i.e. file shares or printers, and then some). This can be used to crash such a system from afar by feedig it rotten packets. "Exploits are already publicly available.", says CERT.

Microsoft has not reacted - yet. CERT suggests you block the SMB Ports to external networks until a patch from M$ is available.

Quote

Consider blocking outbound SMB connections (TCP ports 139 and 445 along with UDP ports 137 and 138) from the local network to the WAN.

 

Read the full thing here: http://www.kb.cert.org/vuls/id/867968

Edited February 3, 2017 by Questargon
Added "Exploits are already available"

[tlink]

so does this only affect you if you're part of a workgroup or is this even if that traffic is encrypted?

[GoodBytes]

If that happens, it must be someone in the family having fun (beside most uses USB printers). If it happens in a corporate environment, It can be tracked through the switches. I don't think this is a high priority issue.

 

Also, it is Microsoft that needs to issue the fix. Please correct.

[FakezZ]

Right now at M$ headquarters they are debating about the issue and whether to fix it or not kinda like this: 

[leadeater]

11 hours ago, Questargon said:

CERT suggests you block the SMB Ports to external networks

Better question, who has SMB open to external networks? Literally the dumbest thing possible and I'm sure no one is actually doing this.

[goodtofufriday]

50 minutes ago, leadeater said:

Better question, who has SMB open to external networks? Literally the dumbest thing possible and I'm sure no one is actually doing this.

When i started my most recent job someone created a rule to allow all traffic through every port externally . -. It was a sight to see. 

[ChineseChef]

22 minutes ago, goodtofufriday said:

When i started my most recent job someone created a rule to allow all traffic through every port externally . -. It was a sight to see. 

I don't....  Wat??....

 

The only reason I could see someone doing this is because they were that weird level of "know how to change stuff to make it work", but also had no idea what they were doing and why it worked.  Like knowing to change a proxy server on your corporate network or something, but having no idea why it works or what is actually happening.

 

Or they were testing something and forgot to reset it?  Which is worse in my mind, cause it means they knew it shouldn't be open but were so careless they forgot about it.

[goodtofufriday]

2 minutes ago, ChineseChef said:

I don't....  Wat??....

 

The only reason I could see someone doing this is because they were that weird level of "know how to change stuff to make it work", but also had no idea what they were doing and why it worked.  Like knowing to change a proxy server on your corporate network or something, but having no idea why it works or what is actually happening.

 

Or they were testing something and forgot to reset it?  Which is worse in my mind, cause it means they knew it shouldn't be open but were so careless they forgot about it.

I tried to find out why. Never got a real answer but it seems like they did to try and solve the IP phones constantly dropping calls. 

 

The actual issue was a bad wan fail over rule with an extremely low latency threshold. The main wan was on time warner,  which always has latency spikes. So the wan would switch to their second isp, thus cutting out all the calls.