Slashdot Mirror
Cisco Flaw Opens Routers to Attack
Jack writes "Cisco is suffering from a serious flaw in its router operating system, which might allow execution of remote code: 'Cisco has warned of a new flaw in its IOS router operating system which might be used by attackers to launch denial of service attacks or take over IOS-based devices. The flaw causes to buffer overflow due to incorrect handling of user authentication credentials.'"
It's been pretty standard to ACL off authentication methods from unknown or untrusted networks for some time.
If you can only auth from a known network, then an overrun in that auth process still requires access to a restricted location, which will stop 99% of attacks (which are usually automated these days).
Mooniacs for iOS and Android
Interestingly enough, there is some truth to that. Lets face it, if a vulnerability is fixed in a patch before it is announced, then there is going to be less chance to abuse it.
However, many companies for whatever reason seem to take ages to release a patch. At this point, it's a good idea to publicly embarass them by releasing details.
Anyone who releases a proof-of-concept exploit is just completely bloody irresponsible. I got a phishing scam email a while back with a proof-of-concept used in it verbatim. Giving the kiddies the tools they need does not improve the situation.
And now I eagerly await the first idiot who replies to this with the same cliche crap about 'security through obscurity'.
I have a close friend who worked at Cisco for a while. The company had massive layoffs in 2001, followed by countless little series of layoffs in 2002, 2003. Tons of good engineers were supposedly let go. You wonder if the lack of engineering resources is beginning to catch up with them. All these years in the trenches shorthanded will leave the product more vulnerable than ever.
You'd be amazed at the things that you'll screw up on code-wise during a crunch period when you've been up for days on end trying to meet the deadlines that the pointy-hairs have set for you.
We're still human in theory at least, so mistakes will happen and in a piece of software that's *that* big, it's really easy to miss them.
Everything I need to know I learned by killing smart people and eating their brains.
Doesn't anybody use VLANs anymore? Maybe I'm ignorant here (it's a big world and all), but why should Windows clients be allowed to talk to eachother on the network?
Would you please describe your VLAN solution that prevents Windows clients from talking with each other on the netowrk while allowing them to talk to various servers. Please address how the solution scales to support implementaitons with tens of thousands of clients, as well. I'm geniounely curious.
Doesn't anybody use VLANs anymore? Maybe I'm ignorant here (it's a big world and all), but why should Windows clients be allowed to talk to eachother on the network? Especially if there are VPN nodes and/or soft-spots in the network implementation? Simple VLANs and the usage of DMZ's for outward-facing servers have worked for us so far; any virus infections have been localized to a PC at a time. There's always the ol' email entry point, but that's what clamav is for, right? ;)
vlans don't inhibit broadcast or unicast traffic on the same vlan, so unless each workstation is on a separate vlan (which I can't imagine, as it wouldn't scale), vlans aren't useful for isolating workstations from each other. They are, of course, useful for isolating workstations from other network devices.