The man who saved the internet

[pendell]

As seen at Ars Technica , one Andre Freund was working along in his job as a security engineer at Microsoft with the intent of troubleshooting a 500 ms delay in a compression utility. Truly, the most exciting work in the world.

He found that it was due to a malware exploit being merged into open source which would have added a back door to every infected computer.

Great discussion on the exploit here .

So I guess Mr. Andre Freund is the Stanislav Petrov of the 21st century.

Respectfully,

Brian P.

[veti]

Makes me wonder... How many times has this happened and not been detected?

On the other hand, it's reassuring that it was detected before being deployed. That's a system working as intended. But does every release get the same level of scrutiny? - because the attackers only need to get lucky once.

[Ionathus]

Reminds me of the quote from a popular article:

...and if these people stop, the world burns. Most people don’t even know what sysadmins do, but trust me, if they all took a lunch break at the same time they wouldn’t make it to the deli before you ran out of bullets protecting your canned goods from roving bands of mutants.

[Smoutwortel]

The lessons I pull from this story are:



Even the scariest threat actors have to sleep:
The time of posting is quite telling in what area someone is.

Two years is a lot(try explaining that to a city planner).

Open review works(caught a two year attack a month after it materialized).

Edit{
The layered release cycle works(the targeted infrastructure was safe from the attack, because they use slow releases).}

Code checking tools work(valgrind).

Binary commits shouldn't be accepted without a good explanation why it has to be binary and nothing else and being fully documented as which part does what and than only after review of someone who can read it.
Yes, it's true that source commits can be malicious too, but a. they can actually be reviewed without reverse engineering, b. most malicious commits are binary, c. it allows for an extra layer of automated code analysis.

High level attackers are selfish:
Most truly advanced stuff is written with the requirement for a secret key and the option for a high entropy kill switch. High entropy unique environmental information and hard coded credentials are thus telltale signs of an attack(and also bad practice, so cracking down on them won't hurt code quality).

Source code is data and should thus be unable to edit any current program on the system without active user permission.

Maintainer feature bullying should be cracked down upon.

It's too easy to hide from debuggers:
Every attack I've seen so far had debugger hide features. We could make research easier and computers safer if we stopped telling all programs whether or not they were being debugged. There're very few legit uses for it and it makes life way too easy for malware writers.

[gbaji]

The lesson I pull from this is "This... right here, Mr CIO, is why we use OS/distros that are 5+ years past release in our production environment".

In the enterprise world, there is a balance between "how valuable is the newest/latest release to our business really" and "how much risk does the newest/latest release pose in terms of security and stability?". And that balance is usually skewed quite a ways away from anything near "bleeding edge", or anything that was once "bleeding edge", or well, anything that hasn't been searched, scanned, checked, verified, and tested by a zillion people, and now is sitting gently on nice green pasture chewing on grass contentedly, doing exactly that which it is supposed to do, and nothing else.

I've worked in the IT industry since before the term "IT" existed. There is one thing I have learned (ok.many things, but this is a biggie): All software has bugs when released. All major releases (and some minor releases) will include exploits and vulnerabilities. All OS updates, especially major ones, will also have exploits and vulnerabilities. Oh... And most of those exploits and vulnerabilities? They will be the same ones that have been released (with only slight variations), like clockwork, in every OS update/release since the dawn of time. Literallly. Every. Single. Time.

Also learned? The standard time frame from initiial release to realizing that "Oh crap! Our new release has a major exploit that we should have known was there because it's basically the same one that is released every other time a major relase is made, but we're all new and thought we knew better than the last 100 teams who did this", is about 3 years. That's the life cycle between "we just released this totally new thing, that's totally cool, and we're all super stoked to have folks use it, cause it's like way better than the old version that did the exact same thing, but had all the bugs removed over time" and "Ok, we actually think we got all the bugs and exploits cleaned out, so we're passing the torch to the new team, who we are told is planning to push out their new release of the same software again soon. Don't worry. I'm sure they'll do fine. The've got some really cool ideas and have completely re-written the entre section of code that we just finally finished fixing. I'm sure it'll be perfect!".

That's not to say don't use bleeding edge distros and sofware. Absolutely do. Use it on that web server you don't care about and use to distribute cat videos. Use it a lot. Invite people to use it too. It's brand new, so make sure to really put that thing through its paces, right? Oh... And make sure to log into tech forums and really encourage young admins working on college campuses, and building their home systems, to use these things and all their super neato new features (that suspiciously do exactly what the old code did, but... you know... newer). And hey. When you call them "chum" on said online forums, they'll certainly think you are just being friendly, but have an old school way of speaking...


Yes. I am evil. But it's a dog eat dog world out there, and someone's got to wear the milkbone underoos.