Magnitude of glibc Vulnerability Coming To Light (threatpost.com)

msm1267 writes: The glibc vulnerability disclosed this week has some experts on edge because of how DNS can leveraged in exploits. Dan Kaminsky said that while man-in-the-middle attacks are one vector, it would appear that it's also possible to exploit the bug and attack most Linux servers via DNS caching-only servers. 'This would be substantially worse if it went through the caching ecosystem; 99 percent of attack vectors go through that system,' Kaminsky said. Glibc, or the GNU C library, is used by most flavors of Linux and also a number of popular web services and frameworks, giving attacks potentially massive horizontal scale. The major Linux distros have patched and pushed updates to servers; source code is also available for homegrown Linux builds.

Comments

Too bad

[Anonymous Coward]

It's a shame there isn't a systems programming language that prevents buffer overflows from existing in the first place.

Re:Too bad

[Anonymous Coward]

It's a shame most companies employ shitty, incompetent programmers who can't write software that doesn't contain buffer overflows.

Re:Too bad

[olsmeister]

It's ridiculous to blame it on programmers who had no idea that the tools they were using had problems.

Re:Too bad

[Anonymous Coward]

I'm afraid the irony of your comment will be lost on this crowd, son.

Re:Too bad

[HornWumpus]

Those programmers are 'shitty, incompetent programmers' if they can't be bothered to learn about the problems their tools have. All tools have problems. It's their job to understand their tools.

Re:Too bad

[Anonymous Coward]

The problem with your theory is that essentially EVERY project of complexity more than "hello world" written in C has been shown to be a security nightmare.

Even the best programmers are unable to keep such minutia in their heads for a huge complex project. It is not a reasonable approach to expect a fallible human being to do by hand what the tool should do automatically.

Your opinion sounds just like the pilots in the 1940's who said, "The crashes due to pilot error are just due to bad pilots not remembering the checklists". But every else realized that is not how human brains work, and started making pilots read the checklist each and every time from paper, rather than try to remember it, and the accident rate plummeted.

It's long past time for the tech industry to get serious about security. We can't keep cowboying the shit out of things and hoping the same old approach will somehow produce different results this time.

Re:Too bad

[Anonymous Coward]

HAHAHA. What a ridiculous statement. Know all the problems all their tools have, or get work done. I think most companies will choose the later.

Re:Too bad

[Anonymous Coward]

The "insecure" C functions that don't have the buffer overflow problems were replaced in C99, Anyone still developing against pre-C99 needs their faces slapped. Yes those _s functions have been around for ever, and Microsoft (despite pleading with users to switch to c++) have been warning against using insecure versions for a decade.

C++ isn't any better, and is in fact much worse for security since "secure" programming is about 100x slower (put and get functions) than just accessing the member variables with public.

If you want to get kids to program securely, you have to teach them C. Once kids understand what the underlying C library does, then teach them how C++ or Swift, or whatever else you want to teach is more secure than C by programming a certain way, and less secure than C by directly accessing variables.

Re:Too bad

[NotInHere]

So the claim is that Rust isn't a systems programming language? Or is the claim that rust doesn't protect you from bugs like this? I'd say both claims are wrong.

Re: Too bad

[Anonymous Coward]

Do both, be tired.

Re:Too bad

[Nunya666]

Or even the latter.

Re:Too bad

[HornWumpus]

In the real world, getting work done means knowing the well understood problems with your tools. It's not like buffer overflows where not mentioned in everybody's introduction to C (course/competent self study). Explain to your boss that sanitizing inputs took to long, so all the tables in production got dropped...I hope you're 12 or at least don't code for living...seriously.

Thanks for volunteering to speak up for all the other shitty, incompetent programmers out there BTW. Way to jump on that grenade.

I'll grant you there are edge cases where tools are so shitty, you can't possibly know a tiny fraction of the serious problems. I'd argue those tools don't belong in production.

Re:Too bad

[Anonymous Coward]

Even the best programmers are unable to keep such minutia in their heads for a huge complex project.

Many people that I work with think I'm BSing them when I say I have a poor memory because I can "remember" so much that others cannot. I don't. I just use my logic to recreate and assume my logic is correct.

I actually have a disability with remembering stuff, from a head injury as a child . Because of this I did very poorly in school. To work around my limitation, I learned to very quickly simplify and abstract ideas to the point that I don't need to remember almost anything, just that the code does sane things in all cases. I spend a lot of time thinking about cases, especially failure cases. This allows me to quickly use reasoning to fill the gaps in my memory. Instead of memorizing, I just re-think through the problem and assume that my past-self already thought of my current case and thought the same way to create the same solution. Based on these assumptions, I can keep crazy small details of very large complex projects in my head that others cannot, even though I have issues remembering stuff.

You might say I remember through thinking. This actually has some advantages. My though processes become linked, similar to memories can be linked. Thinking about something can trigger abstractly related thoughts and quickly change thoughts, quickly switching between low level and high level abstractions.

Unfortunately this way of thinking does not apply to isolated facts, like someone's name. It may take me a few months to remember a person's name, even if I see them every day and try my best to remember them.

Re: Too bad

[Anonymous Coward]

I would like to see your source code tracked through all its versions; and if you have one exploit or bad piece of code, off with your head.

Seriously people, it's not easy finding bugs,
If it was we'd have none. All software has bugs, it's just a matter of are they exploitable or not. It happens when you program in C and sometimes C++. Deal with it.

Re:Too bad

[Anonymous Coward]

Odd, I don't remember writing this.

Re: Too bad

[cyber-vandal]

In a perfect world where there are only super amazing developers such as yourself who never make any mistakes this is true. In the real world it's better to have a language that prevents dangerous errors like buffer overflows because most of us aren't a programming God like you clearly are.

Re:Too bad

[Aighearach]

Don't worry, I'll work on the latter later. Right now I'm busy... uh... compiling. Yeah. I'm uh recompiling everything because of the glibc vulnerability. Yeah, I'll check in a progress report later.

This is the only employee you have left when you expect programmers to magically know about problems in other people's code just because they used that software as a tool.

Imagine expecting a factory worker, even an engineer working in a factory, to know the inner workings of the pick-and-place machine and predict all serious future bugs. It may even turn out that glibc has more lines of code to analyze and memorize than the pick-and-place firmware! And that is just one library. And when they start reading it, they'll realize they have to learn everything about the OS kernel so that they have the context to understand libc, and then they still don't understand it all because they have to consider the CPU implementation details, and all the motherboard subsystems. And the CPU probably has secret microcode, so you eventually just have to apply blind faith and trust an API when you get to the (fake) bottom! But there are actually still more turtles below you at that point.

All of that said, of course they're shitty programmers; all the applicants were humans. And according to various people with lots of letters after their names, the AI is even scarier. It makes sense when you realize that the "artificial" intelligence is actually human intelligence reduced to code and then left to free-associate.

Re:Too bad

[Aighearach]

If code-thrash continues to be common, and "bug-fixes" for non-security-related bugs are mixed together with security fixes and even new features, with a mono-culture system of a single "latest" version that contains all types of changes, then these bugs will never end. They will continue forever in that scenario. Luckily, eventually computers will not seem new, and so code thrash will not continue to be interesting or profitable.

Give it a few hundred years, things will settle out.

Re:Too bad

[Aighearach]

You might have an off-by-times-negative-one error in there, oops!

How can you preach about not making known C-language mistakes when you still make known English-language mistakes? Is it presumed that programmers have an easier time writing perfect C than writing perfect English?

If they stopped thrashing the code and put the new features in a new product, the existing product would reliably improve over time, regardless of what types of idiot mistakes they started out with. As long as the code is being frequently updated, it will have new bugs. Humans make mistakes, it is a fact and you are not immune. You are wrong to insist that it is somehow dysfunctional for humans to make known mistakes. Mistakes are the expected nominal condition!

How would they know to use C99, but not to switch to C17 or whatever comes in the future, that will doubtless have new bugs? And if they were using a clib from pre-C99... would it even be vulnerable to this bug? (no, it was introduced much later)

If the code is being continually updated, there is no escape from continually having new bugs and security holes. If you only fix real bugs, and don't add any features, then you still have new bugs in the fixes but the frequency will go down over time because less than 100% of new code is actually a bug, and so eventually the bug generation frequency would average less than a byte.

Re: Too bad

[HornWumpus]

Automate catching a simple bug like buffer overflows and you leave developers too retarded to find the more serious memory map related exploits.

See also: Every Java only programmer you ever met.

Re:Too bad

[HornWumpus]

Nobody is arguing about glibc. That's well understood to be a giant 'ball of mud', so nobody can know all it's problems.

We are arguing about the C language. To some extent the C++ language. AC in particular thinks knowing that unchecked buffer overflows exist as a class of exploits is too much to ask of C programmers.

Re:Too bad

[Anonymous Coward]

I operate the same way. I have a horrid time remembering proper nouns (e.g. people's names) but I remember functions, systems, relationships quite well. I use similar techniques where I rely on my analytical skills (which are quite strong) to get me through. I very frequently end up dancing around words I can't remember, substituting synonyms, descriptions ("your friend who we recently had dinner with", "the person in the red shirt"), and often use fillers like "thing", "stuff", "you know", or expletives. I always did awful on exams that required any sort of word recall where I had to provide terms from memory. If there was some sort of wordbank or terms were mentioned elsewhere in the exam I could describe their meaning/function; I have no problem recognizing words, just recalling them myself.

Oddly I have an exceptional memory for music. I can (or used to be able to) name the artist/song/album for thousands of songs, as well as the upcoming melody and sometimes lyrics. Many songs I can identify hearing only one or two notes (if it's the beginning of a song). I can identify many bands from only a few notes even if I'd never heard that particular song before. Many artists use similar sounds or styles at least per album if not for several so it's easy to recognize guitars tuned to a certain sound. My memory still fails a bit on specific band names, but not as bad as most proper nouns. If I can't recall the name I'm still able to provide a lot of associative data, e.g. they were popular in these years, they had these other really good songs that go "da da da", the lead singer is blind and gay, I saw them at an outdoor amphitheater and it was a beautiful evening--most people brought lawn chairs but we didn't think to, so eventually we rented some at the venue since even though we were on a hill our view was obstructed while sitting on the ground, and even though Muse was scheduled to play as an opener one of the members broke their toe so they couldn't come.

I don't recall having any head injuries as a child and wasn't told of any. It's possible I had a stroke as a baby and that damaged some parts of my brain, or maybe I'm "just different" due to genetics or some chemicals present during development. The closest thing I could find to describe it is some qualities of aphasia, which my primary care doctor said I definitely don't have. I recently went to a neurologist--half because I'm just curious what's up with me, half because I suck hard at interviews because it's very difficult for me to recall terminology even if I've used the technology for years--I just completely blank on the words. She also said I don't have aphasia and shouldn't worry about it being dementia/early Alzheimer's, since I've always been this way. Her only suggestions were I could get an MRI to see if I did have a stroke as a baby (for curiosity's sake, nothing would be done regardless of outcome) or go see a speech therapist.

I've never met anyone with similar problems so I'm glad you posted. I think it's strengthened my logic since I depend on it so much, and I definitely provide a unique perspective. People (the ones who give a shit, which are all I care about) seem to understand my way of speaking after they know me a while. I get a lot of confused looks from other people. I work around other things, like writing down shopping lists and grouping items by their location in the store. Or as a graduate student when I TA'd I'd plan out lessons in advance and have notes I could refer to during class. I had a lot of students give me great reviews and say I was the best TA (and one even said best teacher period) they had so far. But if someone randomly asked me some other time about any of the topics I taught, I really would not be able to communicate effectively or be much help. Unless they were willing to provide all the terms (if they even knew them), in which case I'd be able to stitch together a picture from my understanding. But otherwise it would be a lot of "that thing" and "you know", which is useless.

I'm not a morning p

Re:Too bad

[Aighearach]

I'm not sure you're going to get very far in your communications by insisting that the context is only idiotic off-topic language wars and not the actual context of the discussion.

You fail so hard, you don't even comment on what I said, you comment on what you said already, and yet you offer no clarification or correction.

Just presume I understand the context, and chose my words knowingly. You'll have a chance to understand my comments. What you're basically saying is that you can't understand my words, because I'm saying something different than what you said. To which I say, you failed to even try to understand me, so of course you didn't. I'll give you another hint: I wouldn't have wanted to say whatever you already said.

Yet another hint: language wars are so brain-dead, most of the programmers who respond to those threads will be discussing other points. Especially when the language-war is off-topic!

Re:Too bad

[Anonymous Coward]

So, why are you recompiling? If you'd done your job, you'd link dynamically. Doesn't link dynamically, don't know your tools, spends time whining on slashdot. You sound like a real valuable asset.

Re:Too bad

[HornWumpus]

You are trying to change the subject in the middle.

Nobody can be expected to find all the bugs in a library they didn't have anything to do with writing. I won't defend a position you try to put on me and called you on the goalpost move.

Start a new thread if you want to start a new discussion.

Re:Too bad

[Aighearach]

Sorry wannabe bully, you're not going to chase nerds off slashdot by just signing up late and then telling us what to talk about.

If you can't figure out what story you're commenting on, that is not my problem; why would it lead me to change my subject?

You're off-topic, and complaining because my insights have a different focus than whatever you were saying. Get over it. I'm talking about the subject in the story, the same as almost everybody here. If you're talking about something else, that is on you. Don't try to blame it on me, and if you think telling me what to say has any chance to be effective, well. That is also on you.

Get off my lawn, kiddo.

Re: Too bad

[cyber-vandal]

You're right sir super genius. We shouldn't use computers for automation, that would be insanity. We should be programming them using two wires like God intended.

Re:Too bad

[david_thornley]

Speaking as someone who actually uses C++, and who does understand object orientation....

C++ is far better. You can avoid buffer overflows by never using C-style arrays except in interfaces. Use std::string and std::vector and the other container classes, and use .at() instead of [] if your compiler doesn't offer checked [] (.at() is required to be range-checked, while [] may or may not be). Since these are templates, they're very fast. std::sort is normally faster than C's qsort().

C++ has far better memory safety, by using smart pointers. std::shared_ptr does slow down performance, but std::unique_ptr doesn't.

If you have a decent optimizing compiler, get() and put() are about as fast as direct access. If you don't have a decent optimizing compiler, get() and put() are not anywhere near your biggest performance problems. Not to mention they're almost as bad as public variables for encapsulation, one of the bases for object-oriented programming, and should not be used unless modifying that member variable does something meaningful in terms of using the class rather than just exposing implementation details.

C++ has problems of its own, but for the simpler stuff it's much safer than C.

Re: Too bad

[HornWumpus]

There are many programming languages, perhaps C and assembler just aren't for you. Stick with LOGO.

That's what they get

[Anonymous Coward]

For being glib about it. (ba dump)

Re:That's what they get

[Anonymous Coward]

I c what you did there.

Re: That's what they get

[Anonymous Coward]

This comment is showing its age and rust.

Re:That's what they get

[Aighearach]

I was just getting exited over a vacation to the glib sea, but then I saw on the news that it is being invaded by pirate hackers, and everybody says they're really vulnerable so I guess that means nobody has confidence in the local security.

I think I'm going to change my plans and just stay with the hurd until the danger passes.

CVSS score was medium of 6.1

[Anonymous Coward]

The CVSS score is a medium of 6.1 for the CVE. So this isn't as bad as Heartbleed since it requires more environmental factors to be a successful exploit.

Most likely organizations have much worse and easier exploitable vulnerabilities than this.

Re:CVSS score was medium of 6.1

[edtice1559]

CVSS does not take into account how widespread a defect is. A defect with a low CVSS score that happens on just about every machine in the world is in some ways worse than a high CVSS defect that is only deployed on a handful of machines.

So how bad is it really?

[Anonymous Coward]

On a scale from 1 to heartbleed, exactly how bad is this bug?

Re:So how bad is it really?

[Anonymous Coward]

0. It didn't affect anybody. Heartbleed was exploited for years by the NSA to the point it is suspected they planted the bug.

Re:So how bad is it really?

[present_arms]

0 it was patched before it became news :P

Re:So how bad is it really?

[tnk1]

Possibly 0, because it was patched before it was publicized.

However, there are those out there who are able to independently discover and make use of these bugs before the rest of us. Whether they did or not will probably not be known until the appropriate information is declassified.

Like Rust? LOL!

[Anonymous Coward]

We all know about Rust. We know its syntax is a step backward from C, C++, Java, C#, and even PHP. We know its resource management approach is confusing, even when you understand how it works and how to use it. We know there's only one implementation of it, and according to its issue tracker it's really buggy (which is even funnier because the Rust compiler and standard libraries are implemented in Rust and Rust is supposed to have been designed to make bugs less likely!). We know it took them fucking forever get Rust 1.0 out the door, and even then it wasn't stable. We know that it hasn't lived up to the hype since then. We know their leadership includes prominent former Ruby on Railers who jumped ship when it became obvious that RoR was no longer trendy. We know the Rust standard library is quite shitty and lacking. We know that C++ has continued to evolve and can offer pretty much everything Rust offers. We know that the Rust community is quite totalitarian, with an intolerant code of conduct and a mod team to take out anyone they don't like. We question Mozilla's future, seeing as how Firefox's market share is dropping like a rock thanks to Mozilla treating its users so badly and subjecting them to so many unwanted changes in Firefox, and Firefox is really Mozilla's only product that sees use these days. We know that the Servo project, which is written in Rust, is going nowhere. We ignore Rust because it just isn't a viable option!

Re:Like Rust? LOL!

[Anonymous Coward]

Ummm...hello, Ada?

Re:Like Rust? LOL!

[Anonymous Coward]

+1 Please mod parent up!!

Re:Like Rust? LOL!

[slashdice]

Where it gets really funny is... rust uses libc's dns resolver. Which is usually (always?) the buggy version from glibc.

Remember that when people ask why "we" don't rewrite all of libc in rust. I mean, if you want to, that's great. But maybe you should start in your own house. Meanwhile, musl and freebsd have much nicer libc implementations.

Personally, I'm not interested in rust. Not because of the language but because of the developers. I'm not sure if it's a programming language or an experiment in social justice gone wrong.

Re:Like Rust? LOL!

[Anonymous Coward]

It should be obvious that "compiles" and "doesn't crash" isn't the same thing as "works as intended"
It should also be obvious that the important data on a system isn't the operating system or anything else that can be re-installed. It is the user files, the things that are unique. Those are typically something that every program can access and delete at will.
This means that no high level language or no root/user separation will ever protect the things we care about the most.

If someone claims that a problem would disappear by using a particular language then you should probably not let them near anything important.

I wish schools would program more in low level languages and less in high level sandboxes.
What programmers need to learn is good programming habits and discipline.
When sloppy programming leads to an unwanted reboot you get good programmers that doesn't just modify and compile until it appears to work.

Re:Like Rust? LOL!

[Anonymous Coward]

Yeah, I've found the Rust community to be very... odd.

I don't mean this in an insulting way, but I suspect that autism and/or Asperger syndrome runs rampant throughout the Rust community, to a degree far more severe than we see even within the wider IT and software community.

For example, they are extremely focused on achieving "correctness". This is something that's highly subjective, yet they try to come up with a one-size-fits-all objective definition. That's a common trait among those suffering from autism and Asperger's. They've ended up creating a language that meets their definition of "correctness", but that's otherwise very inflexible.

Their extensive code of conduct is another example of this. It's like they want to programmatically specify exactly how people should interact socially. Perhaps they're so focused on their CoC because, due to autism or Asperger's, they find normal social interaction difficult or even impossible? Of course, social interaction cannot be as strictly controlled and specified as they seem to want it to be.

It's also quaint how much emphasis they place on diversity, when nearly all of Rust's contributors are young white males. There's nothing wrong with that, of course. It's just that the extreme and unrelenting focus on diversity, despite a total lack of it, is a trait commonly associated with autism and Asperger's.

I've also noticed that they're extremely sensitive to legitimate criticism of Rust. Whenever Rust comes up at, say, Hacker News or Reddit or somewhere else where a lot of Rust's developers and users are, and somebody points out a flaw, the Rust supporters will attack that person. At Hacker News and Reddit this usually means the detractor, or even just somebody asking a legitimate but "wrong" question, will be severely downmodded. Sensitivity to criticism, and uncontrolled lashing out when subjected to criticism, are also signs of autism and Asperger syndrome.

I'd much rather deal with a programming language community that's actually diverse, and made up of relatively normal people, like the C, C++, Java, C#, and Python communities are. This leads to much more balanced languages, a more helpful community, and a better experience overall.

Re:Like Rust? LOL!

[NotInHere]

It should be obvious that "compiles" and "doesn't crash" isn't the same thing as "works as intended"

True. In fact, even rust can crash under certain circumstances. For example, when the stack gets too large, or when a heap allocation fails. But all crashes of rust are "safe", meaning that they usually don't allow for data modification. And yes, rust doesn't guarantee freedom from bugs. But it does eliminate whole classes of bugs. On the path to more secure programs we do need languages with more additional safety, not less.

What programmers need to learn is good programming habits and discipline.

And the rust compiler enforces precisely those. Without enforcement (or warnings) you go nowhere. Rust's ownership concepts allows one to do multithreading without any fears. Consider a codebase with 500k lines and multiple threads: do you know when and how some thread accesses a shared resource? Most times not.

Re:Like Rust? LOL!

[NotInHere]

We know its syntax is a step backward from C, C++, Java, C#, and even PHP.

Rust has many improvements over C/C++ syntax wise:

* syntactic macros, not "string replacement" macros
* scoped macros -- you don't pollute macro space
* scoped imports
* Nested comments -- no #if 0 trick needed to comment out code that contains block comments
* Blocks {} can have a return value, the ; sign is a separator, not a terminator
* If the compiler can find out the type of something, it is implied, otherwise you have to provide it. Only in recent C++ this is possible with the auto keyword.

Where is the "step backward" you talk about? Yes, they have abandoned the ? operator but that's no catastrophy, is it?

We know its resource management approach is confusing, even when you understand how it works and how to use it.

The resource management is in fact very useful, and I think the strong mutability requirements are a feature. I don't deny that sometimes its confusing, and that it contributes to rust's steep learning curve. But still, git has a steep learning curve as well, and there its certainly worth the effort, too.

according to its issue tracker it's really buggy

Yes, the repo counts 2302 open bugs, but they track feature requests in their issue tracker too. The actual bugs are much less.

We know there's only one implementation of it

Rust is a young language, and unfortunately there is only one implementation of it. Perhaps later on we'll get more implementations.

We know it took them fucking forever get Rust 1.0 out the door, and even then it wasn't stable.

Parts of rust are stable, parts aren't. If you use a release or beta channel rust compiler you only can use stable APIs. The fact that you see unstable features in the API docs as well is only to inform you what's upcoming.

We know that C++ has continued to evolve and can offer pretty much everything Rust offers.

You can write safe code in C++, but there is no guarantee. And C++ is promised to be backwards compatible. It has to support all the unsafe constructs that were introduced some day, most of them inherited from C. And yes, probably a C++ linter can do most of the job rust does as well, but as of now I haven't heard from a good free as in software linter that is as strict as rustc, and when you have to fix tons of linter warnings, you most times still have to basically do a rewrite of the program already. Then you can also rewrite it in rust.

We know that the Rust community is quite totalitarian, with an intolerant code of conduct and a mod team to take out anyone they don't like.

I agree, and think their "code of conduct" is very harmful to their project and makes people think that everybody who likes rust is an SJW. I claim to like rust and hate SJWs.

We question Mozilla's future

Mozilla is the biggest threat to rust's future, I agree. They had managed to publish a quite stable browser for ten years or so, but since 2014-ish they are acting weirdly, and this does impact rust negatively. I hope that rust will stay stable, and won't introduce breaking changes.

We ignore Rust because it just isn't a viable option!

Well yeah it isn't a viable option for super-big projects just yet, with less than one year of stability. Perhaps in five or more years rust has gained enough maturity and large enough support from the industry that its "too big to fail".

Re:Like Rust? LOL!

[Anonymous Coward]

I see one excuse and denial after another in your comment. Then at the end of it you still admit that Rust isn't suitable for use! Why waste your time defending Rust, especially when you already know it's indefensible?!

Re:Like Rust? LOL!

[Megol]

Where it gets really funny is... rust uses libc's dns resolver. Which is usually (always?) the buggy version from glibc.

Remember that when people ask why "we" don't rewrite all of libc in rust. I mean, if you want to, that's great. But maybe you should start in your own house. Meanwhile, musl and freebsd have much nicer libc implementations.

Personally, I'm not interested in rust. Not because of the language but because of the developers. I'm not sure if it's a programming language or an experiment in social justice gone wrong.

IOW: you are crazy.

Re:Like Rust? LOL!

[NotInHere]

I say that it is a young language that still has to get maturity and trustability. Right now its a perfectly fine base to build something upon, but with less than one year of stability, I _do_ admit that probably you shouldn't invest millions of dollars into writing programs with it.

APK time.

[Ash-Fox]

A vulnerability that involves some aspect of DNS, prepare for APK spam, sadly no hosts files can block his advertisements for his software despite his claims it can block advertising.

Re:APK time.

[Anonymous Coward]

A vulnerability that involves some aspect of DNS, prepare for APK spam, sadly no hosts files can block his advertisements for his software despite his claims it can block advertising.

Unfortunately our new overloaf Whisplash says he has 'dealt' with APK...

Censorship has never been a part of Slashdot... until now. Sigh.

Re:APK time.

[Anonymous Coward]

Unfortunately, the slashdot IP address changed dice kicked us to the curb and APK can no longer connect. If only there was some sort of distributed hosts file that automatically updated when IP addresses changed...

Re:APK time.

[Anonymous Coward]

That would be awesome if it that actually happened. Unfortunately, I suspect that APK is secretly a user of DNS. The machine he uses it on is locked in the same closet as his blow-up dolls.

Re:APK time.

[tnk1]

In the event you didn't see his constant ads, APK's activities were a commercial activity on this site, which an ad supported, non-government operated site has every right to block. The fact that he was incredibly annoying and abusive about dealing with criticism is just icing on the cake.

Get back to me when they start dealing with people who aren't billboards for a commercial product whose only other activity is trolling people who provide criticisms of said product.

Re:APK time.

[Anonymous Coward]

Unfortunately our new overloaf Whisplash says he has 'dealt' with APK...

Yes, he implemented a filter which weeds out the spam posts.

Censorship has never been a part of Slashdot... until now. Sigh

1. This isn't censorship, it's blocking spam flooding.
2. Yes, this has existed for many years. Notice you don't see ads for MyCleanPC, Viagra, etc? Same thing.
3. APK is still more than capable of posting here, but if he includes his website or his copy-pasta the filter will block that post.

Re:APK time.

[Anonymous Coward]

I still see APK posting here and there, mostly harassing whipslash, which is a fool's errand. But he's not able to spam every discussion thread with 20 posts full of bold italic psycho=>babble anymore, and I call that a victory. I'm rather enjoying the new /. ownership so far.

Re:APK time.

[Anonymous Coward]

If only I had mod points. And logged into an account instead of posting anonymously.

APK was a festering tumor on /. I'm glad his bullshit is gone.

Re:APK time.

[Ash-Fox]

If you look at my recent post history, you'll see most of those replies have been to APK. He's alive and well.

Re:APK time.

[Anonymous Coward]

Censorship has never been a part of Slashdot

Old guy here: 2001 called and begs to differ.

Removing a single comment, even a single commenter is not censorship. It's maintenance.

Still on DVL

[sinij]

Still on DVL (https://en.wikipedia.org/wiki/Damn_Vulnerable_Linux), so I must be secure from this...

Re:Still on DVL

[Anonymous Coward]

Clcikable link

open sores FAIL ... again

[Anonymous Coward]

Once again proving that the open sores model of software development not only results in lower pay for up and coming developers (and often a requirement for NO pay when you factor in how you have to have a big github contribution history to even be considered for any new job these days), it also results in WORSE software. Every single fucking week we discover yet another massive vulnerability in core internet software caused by amateur software developers posing as professionals. This is why I am increasingly advocating for an end to open sores culture in software development. I regularly give talks at my university arguing why open sores has been nothing but damaging to our profession and find it encouraging to see how every time I do so more and more people attend. Open sores has been an absolute disaster for programming and it is well past time we put an end to its sacred cow status.

Re:open sores FAIL ... again

[Anonymous Coward]

I regularly give talks at my university arguing why open sores has been nothing but damaging to our profession and find it encouraging to see how every time I do so more and more people attend.

Why university and not in a professional environment like business seminars?

Re:open sores FAIL ... again

[Anonymous Coward]

I'm still an undergraduate student. I fully expect to be able to make a living in the industry though, and I intend to use whatever skills and time I have to educate as many people as possible about the massive fraud that is the open source "movement". It is time to take back programming from the narcissists and the amateurs.

Re: open sores FAIL ... again

[Anonymous Coward]

LOL, so you are an undergraduate with 0 experience giving lectures to other undergraduates with 0 experience. Got it.

Talk about the blind leading the blind.

Re:open sores FAIL ... again

[JakartaDean]

I'm still an undergraduate student. I fully expect to be able to make a living in the industry though, and I intend to use whatever skills and time I have to educate as many people as possible about the massive fraud that is the open source "movement". It is time to take back programming from the narcissists and the amateurs

... says the person who just admitted he doesn't get paid to program.

Re:open sores FAIL ... again

[RoLi]

Last year we had two (Heartbleed and the Bash-bug), this year we had one (so far). I am affected by none of them. (My DNS-requests only go to my ISP and I am not afraid they will hack their clients - and yes, I did patch it anyway.)

Before that we had several years without any serious one.

IIRC, the only one that ever affected me was 2002 (or so?), the big SSH vulnerability.

In all other cases some special conditions were needed for the exploit that didn't apply to me (for example the Bash-bug didn't affect any of my servers because I don't run CGI and on top the default /bin/sh points to dash and not bash.)

However every serious Linux vulnerability is immediately going through the media - because it is so rare.

In the future, these bugs seem also increasingly unlikely because people immediately check the affected packages for security vulnerabilities (and AFAIK they also fixed a couple in bash).

Don't forget your statically linked executables..

[Kevin by the Beach]

A patch to a .so file is a great fix for most things... But, if you build your own statically linked executables please "make clean", "make"

Just a friendly public service reminder from the "Grey, but still alive"

Defense

[Anonymous Coward]

iptables -t raw -A PREROUTING -p udp --sport 53 -m length --length 28:2000 -j DROP
The above line will block any attack based on this vulnerability.
It may impact some unusual but legitimate queries, though. Normal DNS queries usually have small enough responses to fit in this range.
If the above line is on a Linux machine that is performing as a trusted caching DNS server, it will also protect the clients from the attack.
You might be able to get a few more bytes into the threshold (because there are headers in the DNS protocol) and I am not exactly sure where the overflow happens (raw packet, UDP payload, DNS payload, etc.). As a bonus, this will also drop unreasonably small packets.

Re:Defense

[Skiron]

Also add:

edns-packet-max=512

to your dnsmasq.conf if you run a local caching DNS server.

Re:Defense

[cnettel]

The bug can hit you with DNS over TCP as well. While that is somewhat of an oddity, I am not yet confident to say that you can rule it out, especially if you have a MITM that might be able to trigger fallbacks. Since the TCP response could be fragmented over several packets, things rapidly grow beyond iptables capabilities there. (But the "TCP DNS response fragmented over several packets" would thankfully not propagate through layers of caching internal DNS servers.)

Re:Defense

[Anonymous Coward]

iptables -t raw -A PREROUTING -p udp --sport 53 -m length --length 28:2000 -j DROP
The above line will block any attack based on this vulnerability.
It may impact some unusual but legitimate queries, though. Normal DNS queries usually have small enough responses to fit in this range.
If the above line is on a Linux machine that is performing as a trusted caching DNS server, it will also protect the clients from the attack.
You might be able to get a few more bytes into the threshold (because there are headers in the DNS protocol) and I am not exactly sure where the overflow happens (raw packet, UDP payload, DNS payload, etc.). As a bonus, this will also drop unreasonably small packets.

wut

no, if you read the google post, you need to block UDP 512+ and TCP 1024+ sizes, but that also breaks DNSSEC...

iptables -t filter -A INPUT -p udp --sport 53 -m connbytes --connbytes 512: --connbytes-dir reply --connbytes-mode bytes -j DROP
iptables -t filter -A INPUT -p tcp --sport 53 -m connbytes --connbytes 1024: --connbytes-dir reply --connbytes-mode bytes -j DROP

Re:Defense

[Anonymous Coward]

Or take a dump on your mother's tits.

strlcpy() isn't good enough for glibc.

[emil]

No, it "only leads to other errors".

Funny, I haven't heard of any showstopper bugs in OpenBSD libc - not this year, not ever. And it's ubiquitous, since I'm running it on my phone.

This bug, after ghost, would be a good opportunity to take a step back for a serious assessment of what must be removed for a secure system.

Re:strlcpy() isn't good enough for glibc.

[Anonymous Coward]

I'd rather be a redneck that just know how to write (whatever language) and solve (whatever problem) rather than a drooling social media drone overly concerned about perception and image.

Re:strlcpy() isn't good enough for glibc.

[Aighearach]

a good opportunity to take a step back for a serious assessment of what must be removed for a secure system.

What to remove?

Features. New features. Old features are fine, they can receive bugfixes only. Refactoring may be done once every 10 years, but only if the code appears sloppy.

Done.

Even Matt's Script Archive became secure over time. Sucky code can be slowly improved until it borders perfection, but only if it still does the same thing it used to do, and no more.

Re:strlcpy() isn't good enough for glibc.

[Aighearach]

OK I'll be sure to only run their code, and not ask their opinions about dinner or politics. ;)

Not sure you really thought through your hate-spew there... the context was actually wrench related in that metaphor!

I assume everybody is an idiot, regardless of success or letters. That helps me to make use of whatever their work product is without getting distracted by love, hate, or other things that are off-topic. Last time I did some auto repair I hired an unemployed wrench-turner to help. He wasn't some genius who could fix any automobile, and he'd have caused me to need an alignment job if I hadn't been paying attention and stopped him from doing it the "works on any car and you don't have to read the book" method. But, he turned the wrenches pretty good. Same thing applies to doctors. They might really try to slip you the poisonous crap medicine that is newly-popular but dangerous. Don't be credulous, don't presume that skills in a field are supposed to imply being an awesome human being, or a philosophical giant.

Re:strlcpy() isn't good enough for glibc.

[bluefoxlucid]

It's the politics part that usually applies. The strlcpy() thing cited is politics, just not governmental politics.

I've had three arguments with Theo. The first was over his claim that position-independent executables were "very expensive," which I responded to by benchmarking the entire execution of a Linux OS and determining that the system would indeed slow down if it couldn't find 4 seconds of CPU idle time out of each day (the hit was 1% or 6%, depending on optimization; but the proportion of time spent in main executable code was 0.018% of all execution, since everything happens in libraries). The second was an argument over whether static checking was useful, in which Theo claimed a tool like Coverity PROTECT would *decrease* code security (OpenBSD now uses Coverity PROTECT to look for vulnerabilities). The third was a buck against his analysis of OpenSSL's Heartbleed vulnerability, which he claimed was vulnerable due to the use of an internal ring buffer allocator rather than malloc(), instead of by virtue of not performing bounds checking (there were *several* points he was wrong on).

Ulrich Drepper argued with Michael Meeks about a lot of dynamic-link-time optimizations, then huddled down for a month and released the same code with his name slapped on it. He's got a history of NIH and of stuff like you see with strlcpy().

All of these things are political battles. Theo's issue with PIE was that PaX and GRSecurity were pushing PIE, and he didn't think about that for W^X; his issue with Coverity was that he'd been loudly proclaiming OpenBSD is perfect and secure, and mocking other projects for having all these holes; and his main attack on OpenSSL was basically a large claim that we'd have seen Heartbleed coming if we used OpenBSD malloc() (again: OpenBSD will save the world!). Drepper similarly is trying to prove the universe revolves around him.

These are people who wrote operating systems, or significant parts thereof. They say and do really fucking stupid things, constantly; they've got one good trick and a huge padding of wargable. If you watch, you'll see they screw up technical concepts they should know dead cold because they're more focused on politics.

It's not really binary. Humans are complex, and that complexity gives you about a billion ways to prove you're an idiot. This works so well that you can have genius-level skill in a highly-complex discipline and still be an idiot *within* *that* *discipline*. Matthew Garrett occasionally accuses Linus Torvalds of this, and not just because he's butthurt about being associated with Microsoft Blowjobs.

Re:strlcpy() isn't good enough for glibc.

[Aighearach]

Dropping names to brag about disagreeing with famous people does not cause me to presume that there will be technical insights that I should read the details to find. Rather, it tells me that you're biased and have a bone to pick, and were not able to successfully remove the bias to create a technical discussion of the issues. So your attempt to argue finer points won't even be examined. There is too much available noise for that to be reasonable. I have to be convinced that a signal has low noise before even bothering to worry about what the content may (or may not) actually be. Such is the situation that information glut blesses me with.

Political battles about code are crap. If you're more willing to thrash code than [some random famous guy], your code will introduce more bugs than his. And if he's famous for having stable code that often lacks bugs that the upstream had, because it gets cleaned up once and then left alone, then you'll have a really hard time convincing people to both care about code politics, and also take a revolutionary stance.

You might be right about the details you claim. I'm not going to analyze them. But if they're all correct, I'd be on the other guy's side. Code thrash is the source of most security bugs. Notice that glibc has been around for decades, but this bug was only introduced in `08.

And if you misspell his name to create a pejorative pun, then I know you're just some asshat. What did he really do, steal your Caribou board?

Re:strlcpy() isn't good enough for glibc.

[bluefoxlucid]

Then you restrict your access to information, and have no way to analyze the technical merits of any point anyway.

Pejorative puns are fun, especially when you can mix in a or two. I suppose you wouldn't understand the creative process either, though.

Re:strlcpy() isn't good enough for glibc.

[Aighearach]

Of course I restrict my consumption of information. There is an available information glut, and most of it is noisy.

Notice that that doesn't restrict my access in any way.

You are very sloppy in your words, and your thinking. Pejoratives cause you to be ignored. You enjoy it, so I hope you also take full credit for your results.

I find it funny you think I would click an external link; even funnier that the domain name is some TV-thing. ROFLCOPTER

Also, if you're snooty and ready to tell people they don't understand "the creative process," presumably it means you're a hipster. It certainly doesn't imply creativity. Nor does finding amusement in a thing automatically guarantee that it is appropriate or constructive in a technical discussion.

Re:strlcpy() isn't good enough for glibc.

[goose-incarnated]

The third was a buck against his analysis of OpenSSL's Heartbleed vulnerability, which he claimed was vulnerable due to the use of an internal ring buffer allocator rather than malloc(), instead of by virtue of not performing bounds checking (there were *several* points he was wrong on).

I have to agree with Theo on this one - if the OpenSSL devs used malloc rather than their own pool the bug would have been discovered on day two of release. Sooner, ever, if they had run valgrind on it.

Understand that maintaining an internal pool of memory (allocated once at startup) means that tools like valgrind cannot determine out-of-bounds errors.

Re:strlcpy() isn't good enough for glibc.

[bluefoxlucid]

It's an information thing. Creativity is derived from inventory of the brain's contents and the abstract association of various bits of memory. Had you understood that, you might have drawn several tangential ideals from everything I've said; instead you think like a brick.

Re:strlcpy() isn't good enough for glibc.

[bluefoxlucid]

Not really. Out-of-bounds errors would only occur if you intentionally gave the library bad data. Theo's argument was OpenBSD's malloc() would immediately catch an out-of-bounds *read*, but it can't do that without consuming geometrically more memory--the average size of a malloc() allocation is under 200 bytes, and OpenBSD would need to right-align all allocations in an isolated 4096-byte page to do the kind of trapping Theo asserts, meaning something like Firefox would consume around 20GB of physical RAM instead of 1GB. What OpenBSD actually does is allocate miniature heaps with gaps between them, limiting the size and scope, but utterly failing to catch any off-by-1 errors or other likely candidates for exposing an OpenSSL bug like Heartbleed.

In other words: you *could* catch it with Valgrind or OpenBSD if you both already knew about the Heartbleed bug *and* intentionally triggered it. If you ran OpenSSL against normal, non-malicious requests, it wouldn't misbehave; and even a slightly-erroneous request wouldn't necessarily step across the 16-byte word-alignment barrier that the allocators use (i.e. you allocated 27 bytes, you need to write at *least* 6 extra bytes before you're past the 32 bytes of your allocation).

The chances of this actually happening are near to zero. OpenBSD announced they found a constantly-triggered overflow bug in X11 after some 30 years, and they've had their current protections for well over a decade leading up to that. The problem was it *usually* only wrote *one* byte past the end of the buffer; when it wrote an extra 20 bytes in one case, it triggered a crash, and somebody took notice of the crash report. It probably wasn't the first time that happened, as it's unlikely the first person to experience an X crash bothers to look at the logs (unless it keeps doing it).

So yeah, maybe OpenBSD would have caught Heartbleed some time in 2029 if it had used malloc() *and* nobody discovered it otherwise.

Re:strlcpy() isn't good enough for glibc.

[david_thornley]

If OpenSSL had used calloc() or the equivalent instead of malloc(), Heartbleed would have been harmless. If you're writing code that needs security, don't allocate a block and just keep whatever the heck was last in it.

Heartbleed was not a buffer overflow vulnerability, and using Theo's malloc/free would not have helped. An attacker would ask for a buffer of N bytes, and the software would allocate one. The attacker would write over a few characters, and get the rest sent back. Heartbleed was a failure to clear memory that may have ahd something security-significant in it.

Also, understand that using the system malloc/free instead of an internal pool of memory can cause big performance hits, and is unacceptable in many embedded applications.

FUCK_LIBS

[Anonymous Coward]

And i don't mean the political ones. Libraries. And i don't mean the physical ones. Long live static executables.

Re:FUCK_LIBS

[phantomfive]

Static executables use libraries too, they're just compiled in.

Re:FUCK_LIBS

[arth1]

And i don't mean the political ones. Libraries. And i don't mean the physical ones. Long live static executables.

I would think that if you have linked your binaries with libresolv.a instead of the dynamic libraries, you will continue to be at risk until all the binaries that do so have been rebuilt.
With dynamic linking, someone replacing the shared library only has to restart the binaries that still use the old library.
So no, I would venture that those that go the static route are somewhat worse off.

Re:FUCK_LIBS

[Mysticalfruit]

Your solution is even worse... I can easily replace a library that 10 programs are using because it's got a bug... Once that libraries routines are compiled into 10 programs... good luck finding those time bombs.

Re:FUCK_LIBS

[Aighearach]

In addition to the problems with your comment already listed, I'd like to add that avoiding libraries would only mean pasting the code from the library into a single file before compilation. None of the code would be different in the non-library version, and so none of the bugs would be different either.

You could expand it to the more general solution, __FUCK_CODE, but where would you even define it?

Re:FUCK_LIBS

[HiThere]

Well, it's different from that, and both worse and better.

If programs all used static libraries, then there would be an indefinitely large number of versions of each library on each working machine, but each library would only be accessible to the programs that were compiled with it.

This would have the advantage that "breaking changes" wouldn't affect working code. And the advantage that different versions of, say, a browser would be likely to use different versions of each library. THIS would make it more difficult to write a strongly infectious virus, but more difficult to eradicate an existing one. (SOMEONE is going to continue running version myBrowser.x.y.z, so the virus is likely to never go away unless it's wantonly destructive.)

FWIW, the human immune complex has lots of different "library routines" compiled in, but as the system runs the immune complex changes its genetic code (via a cut and paste approach). This is designed to prevent humans from presenting a mono-culture for infections. It's not perfect, but it works pretty well. And this is analogous to something that could be done with static libraries. I'm not really sure, however, that the systems are otherwise sufficiently similar that this would work on current computer systems. It does resemble having a set of virus checkers running in background threads all the time, but there are enough differences that...well, my best estimate is that running a closely analogous system would be so expensive that you couldn't do anything else.

Re:FUCK_LIBS

[Aighearach]

Having static everything would certainly prevent a virus making use of libraries from infecting every process, but that isn't necessary or even desirable to them. Having more different available versions to attack would increase the likelihood of infection. But more to the point with these exploits is attacks generally, not the special case of viruses. If somebody is attacking a system, they're going to attack all of the available surface until they get in, and then stop. Having all those different library surfaces makes it more difficult to predict which attack will succeed, but it makes it more likely that one of them will.

Any immune response that you build is going to either be very limited in functionality, or else an additional attack vector. If you want a bunch of small processes running, each of which might kill another process because it thinks it is misbehaving, you might eventually build a system that responds in a similar way to attack; but it would also have things like allergic reactions, where false positives destroy existing functionality and data. You would have to completely give up repeatability and the ability to predict behaviors; even ones you're programming. And testing would never guarantee continued functioning, even without code changes.

Not every paradigm from nature is going to be applicable to human computing tools.

Re:FUCK_LIBS

[HiThere]

Most viruses/exploits target a particular library running in the context of a particular application. This would fragment their ecosystem. And vaccinations against particular diseases (AKA binary patches) would be possible...but they've be very version dependent.

You're right, not every paradigm is going to be applicable, and I thing, after making due allowances for metaphor translation, this one would be too expensive. But the proposal isn't ALL bad.

Re:FUCK_LIBS

[Aighearach]

Most viruses/exploits target a particular library running in the context of a particular application.

That has a lot to do with the historical way that applications are linked, though. If applications were commonly linked against different libraries, there would be a lot more fuzzing and things going on. The nature of the exploits would be different than they are.

Targeted attacks already use the techniques that would be more common in that alternate world.

The proposal isn't all bad; it may or may not even be bad, generally. But since it wouldn't be able to achieve what it claims, it is more likely harmful that helpful, the same as any random mutation.

It is already fairly normal to spam all inputs with malformed SQL :) My logs are usually filled with it, anyways, on most services. I also see various string overflows being tried on any input.

From a technical perspective, it is not likely to make much progress on these problems at the same time as wanting to constantly "innovate" and have new features. Once people figure out what features they want from computers, then a serious effort to write solutions that won't require constant change can begin. If you don't have code thrash, any of these linking paradigms can eventually reach a state of very few bugs, and very little attack surface.

Minimal impact

[bluefoxlucid]

Has to get around stack overflow protection canaries (-fstack-protector-strong or -all), address space randomization, and a non-executable stack and heap. Ubuntu has run -fstack-protector-strong (covers functions calling alloca()) since gcc 4.9 release after 2015-05, according to #1317307. Kees Cook added the -strong feature to gcc, and is part of Ubuntu's compiler team, so it went straight into Ubuntu.

Good luck exploiting this bug.

Re:Minimal impact

[Anonymous Coward]

libc (from glibc sources) is not covered by -fstack-protector (it is not compiled with it), AFAIK. I say that based on the fact that someone @glibc upstream is digging up old patches to allow that (thus, I assume it isn't trivial to just tell glibc to build with that). From that same ML post, I take that *some* of the other libraries provided by the glibc source *are* built using -fstack-protector-*, such as libresolv.

Re:Minimal impact

[The-Ixian]

This sort of sounds like the bravado of someone who is sure that they are protected because they have anti-virus software installed.

Re:Minimal impact

[Anonymous Coward]

Has to get around stack overflow protection canaries (-fstack-protector-strong or -all), address space randomization, and a non-executable stack and heap. Ubuntu has run -fstack-protector-strong (covers functions calling alloca()) since gcc 4.9 release after 2015-05, according to #1317307. Kees Cook added the -strong feature to gcc, and is part of Ubuntu's compiler team, so it went straight into Ubuntu.

Stack overflow protections were defeated long ago, simply by not actually returning from the exploited function (stack overflow protections only verify the stack upon returning). Return oriented programming was invented to get around that. That's why we need ASLR and DEP/NX. They provide some protection against ROP. Unfortunately, Linux by default only provides a very weak form of ASLR. Even if Linux had strong ASLR - or you use something like grsecurity which provides strong ASLR - an information leakage bug may be all the attacker needs to get foothold and circumvent ASLR.

Good luck exploiting this bug.

Complacency is dangerous. You may feel smug and protected - right up until some script kiddie roots your server park. Good luck with that. Me, I'd trust the people who actually know about this sh** - and start making sure that *all* of the servers are patched and protected.

Re:Minimal impact

[bluefoxlucid]

Anti-virus software is an arms race. This is a change to the fundamental behavior of the compiler toolchain and produced code.

Think like someone tells you dishwashers are dangerous because they use high-temperature hot water, and then your glasses all crack because they drop from 145F as they're exposed to the cold air when you open the door after a wash cycle. You then point out that your glassware is all borosilicate glass and can take a temperature drop of 120 degrees celsius across 1 second without damage. Going from boiling to ice water won't break your glass; heating it dry over an acetyloxy torch and then dumping it in an ice bath *will* shatter it.

What you're looking at here isn't a system that catches one specific attack signature. You're looking at an attack which fundamentally relies on overflowing a buffer on the stack, rewriting RETP with an address on the stack that contains code injected as part of the overflow, and then jumping into that code on RETL instruction. This executes your code from the stack.

Meanwhile, the software being attacked stores a runtime-randomized word between the stack variables and RETP, then verifies it hasn't changed before a call to RETL, so you have to guess a 32-bit or 64-bit integer (1 in 4 billion or 1 in 16 billion*billion). If that fails, the system *still* has randomized the stack base, so you have to load a value into RETP which points to your code on the stack, which can be in any of thousands or millions of locations. Should you manage to guess both a one-in-four-billion and a one-in-524-thousand value simultaneously (one-in-2251-billion-billion) (or bigger on 64-bit), the stack is still non-executable: the OS will claim a general protection fault due to trying to execute non-executable memory.

That means this attack can't be carried out successfully without extreme luck (1 in 9.7 billion billion billion) or advanced knowledge of the program's address space (which the attacker must inspect while the program is running--it changes on every run); and even then, the attack has to do something distinctly other than injecting code. Heap, main executable, and library load addresses are also randomized on each run, so luck in dodging out the primary protections leads directly to rolling bigger dice in hopes of getting lucky a third time.

In this particular attack, you can't just launch an attack at a target. You have to gain control of DNS responses for that target, then wait for the target to make a DNS query. All of the above then apply. Good luck.

Re:Minimal impact

[phantomfive]

It can be done. In practical terms, it means you need to find more than one bug to exploit it and get around the protections.

Re:Minimal impact

[Anonymous Coward]

Unfortunately, Linux by default only provides a very weak form of ASLR.

You can get strong ASLR in Linux, you just have to remember to put -D_FORTIFY_SOURCE=2 -fstack-protector-all -fPIE -pie -Wl,-z,relro,-z,now,-z,noexecstack on your GCC command line. One of those options does it, I just don't remember which.

No idea why the default is to prefer speed over security. The average user can buy a faster computer, but they can't do jack to make it more secure.

Re:Minimal impact

[The-Ixian]

While you are probably correct. It still strikes me as hubris to be so dismissive.

Also, you know a lot about dishwashers.

Re:Minimal impact

[bluefoxlucid]

You comment about dishwashers using hot water, but not about glass that can handle sudden temperature differentials?

I'm being realistic. It's like saying you can't do any banking on the Internet because someone could steal your credit cards when you log into your bank site; that worked in 1990, but we've since started using SSL and 128-bit encryption. Banking is safe, and running around screaming that the packets go through a bunch of routers in between and someone might be able to read the data is just wargarble.

To say that this vulnerability is as big a deal as it's made out to be would require you to also acknowledge that ever logging into any banking site, ever, or using any credit card on the Internet would require immediately canceling that card and those accounts because someone has probably stolen them as soon as they went on the wire.

Re:Minimal impact

[bluefoxlucid]

Yes, it requires even-more-unlikely scenarios.

Among those, many of the techniques you've provided require the ability to write to arbitrary memory locations (in which case you can use *that* bug to emulate *this* bug, so no change). Some rely on Windows Safe Exception Handling exploits. One of the methods given is "attack a function that isn't protected", which is a handwave.

The phrack article has a program exploiting itself by inspecting its own memory space and then jumping over terminator canaries. That is: rather than strcpy(buffer, baddata), it strcpy(buffer+offset, baddata). In practice, this means having a way to change the strcpy() call's target--i.e. a way to write arbitrary data to arbitrary memory. The other attack overwrites the shadow pointers, which is another write-anything-anywhere style attack. Both such attacks can fully emulate *this* bug, and so would provide the same capability of exploitation of this bug. In other words: no new risk introduced by this bug.

Core's article is the same: can write to arbitrary memory locations.

Notably, the address space randomization protection would obfuscate the location of the retarray used in StackGuard, making such attacks more difficult in the same way previously stated.

In any case, all of these are ways to get around randomized canaries. They all require the ability to write to arbitrary memory, which gives you a bigger tool to perform a much broader attack. This doesn't defeat address space randomization; and address space randomization doesn't defeat having all memory be exclusively writable OR executable (meaning injecting code flat out doesn't work, even if we hand you all the keys to do so).

Think about that. In 1998, a simple overflow like this would be a quick way to exploit anything on a whim; now it just means that, if you slit the throat of a virgin goat and bathe your naked body in its blood under the light of a full moon on Winter Solstace when the planets are in alignment, you have a 1 in several billion billion chance of crashing the program due to an attempt to execute the stack, instead of crashing it due to a bounds check.

We've come a long way.

Re:Minimal impact

[cnettel]

Has to get around stack overflow protection canaries (-fstack-protector-strong or -all), address space randomization, and a non-executable stack and heap. Ubuntu has run -fstack-protector-strong (covers functions calling alloca()) since gcc 4.9 release after 2015-05, according to #1317307. Kees Cook added the -strong feature to gcc, and is part of Ubuntu's compiler team, so it went straight into Ubuntu.

Good luck exploiting this bug.

Denial of service by crashing the process is of course not as nasty as remote code execution, but it can easily be nasty enough, especially if the properties of DNS would allow you to penetrate deep inside networks and services generally believed to be protected. My personal favorite vector here would be XML exposed to parsers that auto-load whatever DTD or other schema that is specified.

Re:Minimal impact

[bluefoxlucid]

This is all true; and yet the media machine dismisses all denial-of-service attacks, all bugs that just crash your application, and instead jump up and down with white sheets making spooky noises whenever they see the words "Remote Code Execution." The report here is that glibc has this huge, terrifying attack surface turning any application into a hacker back door paradise; that assessment is false.

Did you hear about CVE-2015-1473, allowing a local or remote user to trigger a denial-of-service in glibc? What about CVE-2014-6040, the iconv() denial-of-service causing a crash in glibc iconv(), which converts between encoded 8-bit text e.g. Windows smart quotes, ASCII standard, and Latin-1? Good places to throw HTTP requests that absolutely murder your Apache2 web server. CVE-2014-8121, glibc infinite loop in nsswitch facilities, lets a remote attacker make glibc perform a look-up while already performing a look-up, repeatedly resetting the file pointer forever.

Nobody really cares all that much. "Hackers can take over the entire Internet!" is a better headline.

Re:Minimal impact

[Aighearach]

Most nerds think about the properties of different types of glass with some frequency, because glass is a common material that we interact with in multiple areas of life.

We also hear a lot of idiots say a lot of idiot things, generally consistent with the scene you described. However, I've never heard that one about dishwashers being dangerous. It is hilarious. Absolutely more surprising than knowing about glass properties.

Also, here in the US a "high temp" commercial dishwasher is expected to reach 180F on the rinse cycle. Even the cheap glasses do fine.

*BSD proved many times over time that strict coding practices can defeat these types of bugs. However, they also resist adding features and thrashing working code more than 1 or 2 times initially when porting it in and cleaning it up. I'm not convinced it is reasonable to expect these types of bugs to be avoided on systems where "innovation" in existing libraries is considered a positive thing. How can systems that want to "keep up" possibly avoid repeating these mistakes, or other new ones if you achieve a best practice that prevents the old one?

Re:Minimal impact

[bluefoxlucid]

Dishwashers aren't dangerous per se. It's just that cheap soda lime glass does crack when heated. I've had glass mugs explode in my hand while hand-washing: when pulled out from under the faucet, the cool air caused the glass to contract and crack, sometimes loudly, sometimes energetically. I lost *six* mugs in a set that way, the type made of green-tinted glass that's not thermally stable at all. If you open a dishwasher while the same type of glass is still hot, you expose heated glass to cool air; leave the dishwasher closed and the air inside cools slowly, preventing breakage. Many modern dishwashers include passive circulation facilities which allow the heated, humid air to rise and flow out a rear vent, drawing cool, dry air into a lower vent through a counterflow exchanger, thus retaining the warmth of the leaving air but ejecting the humidity, effectively drying the dishes--and thus they recommend leaving the dishwasher closed for 30 minutes to allow a passive drying cycle (no fans!).

How can systems that want to "keep up" possibly avoid repeating these mistakes, or other new ones if you achieve a best practice that prevents the old one?

You don't avoid them; you mitigate. Avoidance is using C# or Python to eliminate the possibility of coding a buffer overflow and creating a route for native code injection. W^X, PaX, ExecShield, stack smash protection, and other types of execution environment and code generation protections instead surround dangerous code with facilities to react to their flaws.

That is to say: you can still inject code into the application; you just can't get the application to actually *execute* that code. Your program flow is still trashed, your program still crashes, and your system still suffers some kind of loss of service; this loss of service is of a lesser severity than what the same programming mistake would normally cause (e.g. a program crash instead of a remote shell; remote access to a zero-privilege user instead of remote root access).

It's the same reason we build containment buildings around nuclear reactors. The damn thing might melt and vent radioactive dust and gas into the containment building, but that's significantly less bad than venting it into the open atmosphere. You get a massive economic injury instead of the same economic injury *and* an enormous ecological disaster.

As for new mistakes, technology advances when new mistakes become less frequent or less severe. You can still fuck up by the numbers in C#; it happens much less often, and the result is usually not so spectacular. Usually you have to mishandle authorization control, such as by creating an SQL injection allowing the remote user to obtain database privileges (the application presents certain operations to the user, and uses a database account whose set of possible operations encompasses those end-user operations; if the user can insert arbitrary SQL code, he has access to *all* operations the application can perform). Accidentally screwing up your program in such a way as to allow arbitrary flow control redirection is *really* hard in C#.

Re:Minimal impact

[Aighearach]

... I've had glass mugs explode in my hand while hand-washing: when pulled out from under the faucet, the cool air caused the glass to contract and crack, sometimes loudly, sometimes energetically. I lost *six* mugs in a set that way...

Wow, that exposes your debugging skills pretty bad. One, OK. Everybody makes mistakes, one bug is not even a foul. Two, well, your first theory was just that it was a flawed unit. Three, OK, your first mitigation technique didn't work. Six? And then you're going to go on from there to lecture on code quality? You focus a lot on temperatures, I can inform you right now that your hot water heater is not adjusted to specification, and you failed to expect to need to adjust your washing technique to mitigate that.

Programming is hard, and if you disagree, you probably have three to six times more bugs than you would have had if you realized that it is hard. ;)

BTW, the nuclear containment building is not a viable metaphor for the type of code mitigation strategies you describe. And python code does not have less bugs, that is an inanity with a known value.

Re:Minimal impact

[Anonymous Coward]

pie

Re:Minimal impact

[bluefoxlucid]

I simply assumed the glasses were shit, and stopped using that type of glass after they all broke. It's the same principle behind never using perl.

I can inform you right now that your hot water heater is not adjusted to specification, and you failed to expect to need to adjust your washing technique to mitigate that.

You seem to have not noticed it didn't burn my hands.

the nuclear containment building is not a viable metaphor for the type of code mitigation strategies you describe.

It limits the scope of damage without preventing the actual precipitating event. C buffer overflows no longer allow remote code execution, but rather cause denial of service. With privilege separation strategies, you use a non-privileged daemon to sendmsg() a file handle (e.g. TCP connection) to a privileged daemon, which forks off and chroot()s a non-privileged daemon, which then interprets the data, then uses sendmsg() to send the connection and instructions to a privileged daemon, which then switches to the appropriate user, and suddenly sshd is never interpreting a login event as a privileged user. With sandbox strategies, you might do the same, chroot()ing a worker and then using sendmsg() to give it a connection, exchanging processed data with it. Either way, hack these things and you get ... nothing useful. Even in an exploit condition, the damage is contained.

We built a lot of crap around things that could break, and they only break that bad. They break *really* *bad* when they break, but we put a wall around them and so they're contained.

And python code does not have less bugs, that is an inanity with a known value.

Python code doesn't have the same number of remote code execution bugs as C code. It has distinctly fewer remote code execution bugs per thousand lines of code. This is because causing remote code execution in Python is really freaking hard, since you don't spend a whole hell of a lot of time directly manipulating pointers to fixed-size memory areas or doing *anything* *else* that can affect program execution flow outside the boundaries of intent.

It has other, less-important bugs.

Re:Minimal impact

[Aighearach]

I simply assumed the glasses were shit, and stopped using that type of glass after they all broke. It's the same principle behind never using perl.

Didn't read past that. That wouldn't get you to six, it would get you to one or two and then you'd throw away the rest. There would be no reason to wash the remaining one using the same technique that was proven flawed for that unit; deciding the units were all crap would underscore that, not eliminate it.

BTW, welcome to slashdot. No, we don't click video links. This is a place for stuff that matters, not stuff too vapid to write down.

Re:Minimal impact

[Anonymous Coward]

Do you guys jerk each other off as you type paragraphs of bullshit?

Re:Minimal impact

[Anonymous Coward]

...except when compiling shared libraries. Then it's "pic" for some reason.

Re:Minimal impact

[bluefoxlucid]

Why would I simply throw away glasses I could get a few more uses out of? I drive a 2004 Mazda 3; should I get a new car because third gear's been broken for 2 years?

The shit you've been babbling about is more vapid than anything on YouTube.

Re:Hands up

[Anonymous Coward]

Jokes on you, DNS uses pascal-style length prefixed strings like SSL.

That's how we get attacks like heartbleed: "255A"

Re:Hands up

[jones_supa]

Who saw the name of the library, immediately went "oh, another C buffer attack," and rolled their eyes?

It's interesting how these things go.

If this would have been a vulnerability in MSVCRT, everyone would have mocked Microsoft and Windows.

However as this is a Linux vulnerability, the attention is turned to the used programming language instead.

Something to think about.

Re:Don't forget your statically linked executables

[Anonymous Coward]

Isn't DNS one bit of glibc that can't be statically linked? e.g.

$ echo -e '#include <netdb.h>\nint main() { gethostbyname("foo"); return 0; }' | gcc -xc - -static
/tmp/ccgjLWYV.o: In function `main': :(.text+0xa): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

In fact, I think this is a major pain in the ass and one of the reasons muscl libc is gaining so much ground as that allows truly static linked and portable executables.

It would be very ironic if static linked glibc apps were not invulnerable to this bug.

Re:Hands up

[chipschap]

If this would have been a vulnerability in MSVCRT, it would be concealed as long as possible, and who knows when it would be fixed?

However as this is a Linux vulnerability, it was openly discussed and it was fixed at once.

There, FTFY.

CVSS is not always accurate

[mx b]

The CVSS score is a medium of 6.1 for the CVE. So this isn't as bad as Heartbleed

First, Heartbleed was actually a 5.0 base score, so this is more serious if you go strictly by CVSS score (which is not necessarily advisable). Reference.

Second, CVSS scores are based on a certain formula and small set of conditions; in particular, vulnerabilities are scored based on their immediate impact and not necessarily things that occur down the line. In other words, CVSS base scores do not include environmental metrics (There is a CVSS environmental score, but almost no one uses it except for CERT). So looking only at the base score is not always a good indication of severity; possibly its a good first approximation, but it's good to look into the details too. Since glibc is part of pretty much everything out there, this is a pretty serious issue.

Re:Hands up

[Anonymous Coward]

Who saw the name of the library, immediately went "oh, another C buffer attack," and rolled their eyes?

It's interesting how these things go.

If this would have been a vulnerability in MSVCRT, everyone would have mocked Microsoft and Windows.

However as this is a Linux vulnerability, the attention is turned to the used programming language instead.

Something to think about.

And if it was Apple, we'd see a pile of posts telling us about how this really isn't a vulnerability.

Re:Hands up

[Anonymous Coward]

However as this is a Linux vulnerability, it was openly discussed and it was fixed at once.

There, FTFY.

It was disclosed in July last year. That doesn't meet my definition of "at once".
https://sourceware.org/bugzilla/show_bug.cgi?id=18665

Re:Hands up

[joboss]

MS stopped being such a security concern once NAT came around then windows firewall as more of a standard apart from MSIE.

Re:Hands up

[_merlin]

The source to MSVCRT is distributed with Visual Studio - it would be pretty hard to conceal a vulnerability like this.

Re:Hands up

[HiThere]

I wish I didn't have to agree with you. In fact the "speed" with which this was addressed is sufficient to yield some credence to those who believe that it was supported by those who have in other circumstances acted to intentionally weaken secure cryptography, and other secure systems.

I will grant that the evidence in support of this theory is so scant that accepting it counts as paranoia, but similarly it is strong enough that rejecting it counts as living in a fools paradise. As with many situations it the uncomfortable middle position of "well, maybe" that seems most supported by the evidence.

OTOH, it's never fair to rule out bureaucratic inertia. Which isn't, now that I think about it, a much more comfortable option.

Re:Hands up

[Canth7]

And it took 7 years to discover the bug. This is not a win for OSS security. Couple this with heartbleed and it's been a horrendous couple of years for trust of OSS code review.

Apk's making a FOOL of "gothisasswhippedslash"

[Anonymous Coward]

See subject & this post http://slashdot.org/comments.p... hahahahaha so much for htaccess filters, eh folks? Meson shear = APK thru a wet paper bag built by web-wally "GotHisAssWhippedSlash"!

"GotHisAssWhippedSlash" is failing vs. apk

[Anonymous Coward]

See subject & this http://slashdot.org/comments.pl?sid=8777063&cid=51564703 hahahahaha (this? This was just "too, Too, TOO EASY - just '2ez'" & it ALWAYS IS vs. "web wallies" like "GotHisAssWhipped" (by APK) "Slash", lol... so much for his "filters" which are like a wet paper bag against a meson shear! Oh the SHAME of it, hahahahahaha!

Hosts protect vs. dns issues by avoiding it... apk

[Anonymous Coward]

They compliment one other. I don't resolve 'every host-domain there is. Only favorites @ top of hosts (24 for beating indexing > 2++ million records) where you spend MOST time online! It's faster + more efficient than calling remote DNS servers. My program places them at the TOP of hosts for FASTEST POSSIBLE RESOLUTION from LOCAL system memory (hosts = cached like any file) also saves CPU cycles, RAM, + I/O turning off the slower usermode clientside DNS cache service vs. using kernelmode diskcache (no context switch overhead to IP stack this way too). The rest of my hosts files' entries are 3,854,815++ blocked entries vs. malware & ads of many kinds. I use Open DNS REMOTE FILTERING DNS SERVERS (combined with those hardcoded favorites) - not locally as a separate redundant wasteful recursive server or a service/daemon. Free model's good for single home systems not corporate LANS on AD. It LIGHTENS remote DNS loads - admins should like that too!

Re:Hosts protect vs. dns issues by avoiding it...

[Ash-Fox]

What happened to you APK? Did you lose Internet for a few days or something?

"JAWOHL, Mein Furher!" (yea right is more like it)

[Anonymous Coward]

See subject & just to SPITE YOUR STUPID sockpuppet of "GotHisAssWhippedSlash" by yours truly? See here too http://slashdot.org/comments.p...

APK

P.S.=> Weak CHUMP - when will you FOOLS ever learn you are JUST NOT IN MY LEAGUE technically? I mean, lol, you've tried since 2012 to validly technically DISPROVE my points on hosts superiority to all other methods on numerous levels & can't... lol, so you resort to "when the TRUNCHEON is used in LIEU of conversation" & valid logical debate now too?

LMAO @ U - YOU FAIL THAT TOO, chumps... apk

Finished a contract job (was working)... apk

[Anonymous Coward]

See subject - For 28th largest company in the USA, Fortune 50 is what! Good pay, good people (their head of IT is "DA MAN" but younger than I but good person & talented too - from my local area too + the guys I worked with? Truly a "MOTLEY CREW" & nice people) & actually FUN!

I also was able to see a GOOD old pal of mine there too (he's a serious BIG-WHEEL now after 20++ yrs. there) as well thru their IT head (actually REGIONAL northeast head)... was truly nice on ALL possible levels.

* :)

(I.E.-> Was out "making a buck" which I do ON OCCASION for the right companies (always Fortune 50-500) & the right projects that interest me... LITERALLY was a 3 day job (almost continuous) of my usual custom DB applications migration + servers & workstations migration upgrade - cakewalk stuff for me, & good money too... I thank the merciful Lord for granting me a GREAT headhunter in fact!)

APK

P.S.=> That & just SHOWING "good ole' 'LOGE'" (lol) what's what & WHICH END IS UP too today also (See "when the truncheon is used in lieu of converation"? His HAMMERS shatter on me, repeatedly - lol, all linked to here after he shoots his mouth off too repeatedly - & this http://slashdot.org/comments.pl?sid=8777063&cid=51564703 was for 2 REASONS - 1st is to SPITE HIS ASS for his easily seen thru "tactics" exposing the TRUTH behind them, AND of course, to show how WEAK HE IS technically also - just like you!)... apk

APK Hosts File Engine 9.0++ SR-4 32/64-bit... apk

[Anonymous Coward]

APK Hosts File Engine 9.0++ SR-4 32/64-bit http://www.start64.com/index.p...

* Accept NO substitutes...

APK

P.S.=> Does more for speed (hardcoded favorites + adblocking), security (adblocking + blocking known bad sites/servers & dns issues avoiding DNS), reliability (vs. downed or dns poisoned dns), & anonymity (avoiding dns request logs) than ANY other SINGLE "so-called -solution'" out there, bar-none, for less using what you already natively have - unlike "AlmostALLAdsBlocked", UBlock, Ghostery etc. it's not detectable & blockable by ClarityRay/BlockIQ + it uses FAR LESS RESOURCES yet does far more (especially vs. DNS security issues)... apk