Sadly, no idea. 
1 Like
Hi Dan!!
Never met ya, heard some of your talks, and you seem like a hoopy frood. If by some weird, strange accident we ever hang out at RSA or defcon, the first three rounds on are me. 
5 Likes
I didnāt ask what people ācanā do. Iām talking about what they are doing.
It was in the back of my head when I posted, but itās always worth asking. I wasnāt trying to get in the way of your fight either. I disagree with both of you on occasion, but Iām not getting in the middle of this one. Carry on.
It isnāt a fight really.
He can say āOh, you can do this or this or thisā all he wants. Meanwhile, everyone and their brother in ops at every company worth its salt is scrambling to patch things quickly. I know my guys at work were working hard this week.
2 Likes
Sorry. I was probably taking too broad a view there.
Every time this sort of thing comes up, I find myself wondering if thereās something obvious Iām missing. In the physical world, I have have physical locks guarding my front door, my banks safety deposit box, and the property I share with 300 million other citizens. And if by chance one of those locks should fall to a determined bad guy, there is some kind of procedure in place to go after them. Thereās at least a token deterrent in the form of the police. (Yeah, I know whaty chances are of getting my stolen car returned or my burgled stuff back, but the principle is there at least)
In the computer realm, it appears that all the security is wrapped up in the locks, and if they should fall to a determined attacker, there is no deterrent, no investigation possible, itās like a jaw-droppingly wild west free for all. Itās still galls me that the baddies who tried to short airline shares in advance of 9/11 have not been tracked down. Is the their opsec really just that good? Or is it just a matter of no one having enough jurisdiction to follow the data?
If a bitcoin heist can be tracked in real time, how is it that 419 scammers can receive conventional money from their marks without fear of getting caught? Iām not whining just to whine, I really would love to know what makes it so dangerous out there.
Itās as if the pirates were the only ones with boats, and no one had ever thought to invent a Navy yet.
what gives?
1 Like
I wonder how you will patch an embedded printserver box without source that the manufacturer did not release new firmware for. Or an aging ebook reader with wifi and the same problem. Or a āsmartā TV. Or that odd random IoT thingy.
Mitigation has its uses, too.
2 Likes
Your security in the real world depends on a law enforcement system and courts. Jurisdiction is generally clear. Not so on the Internet. Laws and rights and so on exist by territory not by IP block.
1 Like
#YAWN.
āTerrifying?ā Really? Donāt we get enough fearmongering from our politicians already?
Meh. Another day, another DNS bug remediated. Progress continues to be made, slowly, towards a secured distributed global name resolution infrastructure. Much remains to be done.
@Dan_Kaminsky, youāre a fine researcher, and I do appreciate the way youāve managed to get publicity for long-standing DNS issues that people like DJB werenāt able to get into the press, but donāt you ever get tired of these scare headlines?
4 Likes
This is not a YAWN
This is a PAY ATTENTION, GET INFORMED, REMEDIATE ASAP
Googleās already got remote code execution working with this one (on boxes with NX/ASLR enabled). Thatās terrifying.
This is a bug in every unpatched Linux distro from the last 8 years that uses glibc. Thatās a whole bunch of things. This is a bug in a call in glibc thatās used all over the place. When you can get stack buffer overflows in Perl, Python, Ruby, Java, JS, Haskell, sudo, MySQL, and Apache thatās bad. When thatās actually a really short list out of a far more extensive one itās really bad. Thatās widespread.
Admins need to know that they need to remediate this beast rapidly, and if it takes scaring them into recognizing that this is one to pay attention to, thatās okay by me. The alternative is admins that donāt pay attention and leave hosts that get pwn3d and at best wind up serving in botnets that add yet another layer of terrifying, widespread internet breakage.
1 Like
I remediated it before it went public, across two sites and my home network. Hell, Iāve already patched the glibcs on all the non-production non-DNS servers at this point, and will have finished the production ones by this weekend.
Yawn yawn. This crap happens all the time. Itās not terrifying. And if somebody needs to be terrified in order to promptly apply an important patch, frankly they are already unsuited to their level of responsibility, and scaring them isnāt going to work for ever. Itās unlikely to do any good in the long run.
EDIT: The Cisco ASA vulnerability is a lot more annoying; if you patch up to date in order to avoid it, your portal stops working for SMB file transfers. Hmmm, permit a known exploitable remote vulnerability or make a mission-critical box completely unable to perform a primary function? What do you think the pointy-haired bosses will say to that? Makes glibc bugs that have working patches available seem a lot less than āterrifyingā.
2 Likes
Who uses those? 
Windows shops?
Iām pretty sure the ASA is running linux - let me check - ayup. 
Windows shops are moving to RDS these days, which might cut into ASA sales a bit. HyperV licensing is so dirt cheap that better virtualization environments donāt make good financial sense, and you can run your RDS cluster out of a hyperV backend. But there are ridiculous numbers of ASAs out there running site-to-site and ad-hoc VPNs and providing enterprise firewalling (sometimes, all in the same box) so their decreasing use as web portals wonāt have a huge impact.
The CVSS on the ASA vulnerability is a TEN, just like the glibc bug, but here we are ten days after the ASA bug announcement and thereās no patch that doesnāt break something else*. I think thatās a bit more worrisome than a glibc bug thatās trivially patchable, personally. Especially when you realize that rebooting DNS servers is something you can do while they are in use, the clients will just fail over to another server transparently - but thatās not true of ASAs.
(But Iām still not terrified of the ASA bug either, Iām just mightily annoyed.)
*Edit: we have 9.4(2.6) running now which seems to be working.
2 Likes
I didnt have enough time to read before I left the office last night but someone was mentioning that the relevant CVE of the ASA problem has been updated and may require admins to update again.
As you say, these things arent about being terrified, its just BAU.
However, this glibc issue could certainly be ulcer causing for some admins who have business systems which ācanātā be patched/rebooted and or scheduling downtime is near impossible.
2 Likes
One of my cow-orkers found a working ASA version (or at least, one where none of the bugs affect us). 9.4(2.6) has the IKE code patched, doesnāt have the āunicornā bug, and doesnāt have this new SMB problem that the more recent version has. But yeah, there could be more in the pipe, and Cisco is definitely working on the 9.5 version right now.
Thatās true. The Gnu C Library supports a lot more than just DNS services. For DNS servers, though, you can always reboot any time - unless you havenāt implemented the standardized redundant, geographically dispersed and fault tolerant architecture that DNS is always supposed to have. Your clients have three DNS servers they know about (or two, if you are a really really small network) and you wait for each one to come back up before you reboot the next one. Nobody notices it even happened.
2 Likes
This topic was automatically closed after 5 days. New replies are no longer allowed.
