Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Glibc getaddrinfo stack-based buffer overflow

googleonlinesecurity.blogspot.com

Post reply on HN
Print view View original

421–430 of 480 posts

Re: Glibc getaddrinfo stack-based buffer overflow

#421

Post by superkuh »

jvehent wrote: post #299

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 512 --connbytes-dir reply --connbytes-mode bytes -j DROP

Thanks for this. It'll do for my router until a new firmware is out. I tried the above but --connbyte takes a range as input not a single value. Like, "512:8192" or "512:" for "greater than 512". In practice "512:" is interpreted as "512:4294967295". So it ends up looking like,

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 512: --connbytes-dir reply --connbytes-mode bytes -j DROP

Re: Glibc getaddrinfo stack-based buffer overflow

#422

Post by autoreleasepool »

kbenson wrote: post #327
autoreleasepool wrote: post #302

Earlier quoted context omitted.

Again, I'm not talking about performance. I'm talking about low level safety and the difficulties in achieving that in any meaningful way. I wasn't talking about just Rust when I said abstractions cost you speed. It was a (perhaps unclear) general statement about programming. As an aside, unsafe rust is faster than safe rust for a lot of cases. I re-read what I wrote and I fail to see where I attacked or even (God fo…

> Again, I'm not talking about performance. But previously you said "because it can't be safe at such a low level without a performance penalty" which clearly implies performance is part of your argument. This is what I was talking about in my other reply, which mentioned "without narrowing the scope or clarifying your intent". > I re-read what I wrote and I fail to see where I attacked or even (God forbid) criticize…

I re-read this and I see where I went wrong. I thought I had made a general statement about the cost of memory safety abstractions in programming languages that was misinterpreted as a specific statement about Rust and safety in general. This was because I was not clear in my phrasing.

I guess I felt I was being attacked for a point that I wasn't even trying to make. That is, I was responding to you under the impression that I had clearly said something differently than what was interpreted. All without taking the time to read over my own post carefully. Then I got overly emotional which resulted in us talking past each other unproductively and rude remarks on my part.

So I'm sorry for being a melodramatic jerk yesterday. I am actively working on my self control and civility, but I definitely made a mistake here. Hope you have a good day.

Re: Glibc getaddrinfo stack-based buffer overflow

#423

Post by XorNot »

peterwwillis wrote: post #371
asveikau wrote: post #132

Earlier quoted context omitted.

Unless you are linking statically (and I don't really understand why you would) you update glibc and that's it. This question had me feeling kind of old. Does nobody learn what shared libraries are anymore?

The past four years of modern development practices have run screaming from the concept. Learning why the systems used to work they way they did was, like, super hard, so they reinvented the wheel and are running into the same problems that caused us to make shared libraries/COW/etc in the first place.

You've pretty fundamentally misunderstood them if you think immutable practices in anyway damage the ability to deploy fixes. Years of shared library hell is what causes things like this to go unfixed.

Re: Glibc getaddrinfo stack-based buffer overflow

#424

Post by bsder »

pjmlp wrote: post #414
bsder wrote: post #384

Earlier quoted context omitted.

Whose performance was so bad that porting the Lisp Machine software to a general purpose Alpha added multiple factors of performance increase.

C compiler performance in the 80's for home micros was so bad, that functions were basically naked entry points to full inline Assembly. And here we are now discussing how good modern C compilers are. If there isn't the willingness to spend the money to optimize performance, of course it won't improve.

> C compiler performance in the 80's for home micros was so bad, that functions were basically naked entry points to full inline Assembly.

For good reason: memory and disk were ferociously expensive until about 1996-1997.

Things like unchecked bounds make sense when you can barely get your computer to do what you want. Designing a VLSI chip through about most of the 1990's was HARD. Everything was an exercise in how to fit things on disk, fir things in RAM, run enough polygons, or run enough instructions on the emulator to actually boot.

Now: we can emulate a 6502 in Javascript while animating it. We can emulate entire PowerPC chips at real-time speed. So, yeah, NOW allocating a couple of cycles to bounds checking and garbage collection makes perfect sense.

We should have started the conversion away from C in 2000. The problem is that 1) sunk cost keeps design decisions made in vastly different environments around for far longer than is reasonable and 2) we didn't really have good replacement options for C until starting about 2005.

And then the cellular phone revolution hit and put us back to programming like its 1995. Finally, now that cell phones even have an overabundance of CPU, storage, and memory--we now can start to care about security.

Re: Glibc getaddrinfo stack-based buffer overflow

#426

Post by Havvy »

reality_czech wrote: post #401
AsyncAwait wrote: post #243

Earlier quoted context omitted.

The parent actually said "Rust or pretty much anything else", which means any memory safe language. It just happens that Rust came to his/her mind as the first choice probably because it's been talked a lot about lately on HN and memory safety is its explicit focus. I see no "programming languages a religion zealotry" in parents post, but I see a lot of bitterness in yours. Perhaps it's time to reflect.

There are tons of vulnerabilities discovered every month. Most of the them are in Java, PHP, javascript, etc. software because that's what the majortiy fo new code is written in. And those languages have features that can lead to security holes, which C doesn't have. For example, PHP supports eval(), JS has cross-site scripting attacks, Java has classloaders, etc. etc. But somehow only the vulnerabilities in C langua…

JavaScript doesn't have XSS. The DOM allows for XSS vulnerabilities, but that's an API, not the language.

Re: Glibc getaddrinfo stack-based buffer overflow

#427

Post by theseoafs »

autoreleasepool wrote: post #113
School-Cotton wrote: post #74

Earlier quoted context omitted.

Your post is just a bunch of pathos and doesn't explain why you actually think it's a bad idea. There's no technical reason why the C standard library can't be written in a language other than C. Lots of language libraries are written in languages other than the one they're primarily used with and work fine.

I mean, what problem is this solving? There's no technical reason why it can't be done, true. It's still a hilariously bad idea that would never succeed. That's aside from the fact that's a completely pointless wheel-reinventing endeavor. Rewrites in general are pretty difficult to justify. Sorry, I guess my aggressively pragmatic side is showing today. The idea is really dumb. To be honest, "Let's rewrite the C stan…

The problem that it's solving is security vulnerabilities like this one.

Re: Glibc getaddrinfo stack-based buffer overflow

#428

Post by ptaipale »

ivl wrote: post #173
golergka wrote: post #166

Earlier quoted context omitted.

Well, there are areas where freedom to innovate is more important, and then there are areas where liability is more important. May be US (as de-facto main government-level actor in IT and internet) could create voluntary certification that opened up companies to such liabilities? Small startup operating from a garage — no certification necessary, but users are aware that no one is guaranteeing anything. IBM? Level A…

If it was voluntary, I doubt many of those companies would see it as worth the risk. The problem is that these errors happen because so many people are working on interdependent parts. Many times, it's not even your error that can make your software vulnerable. I dislike making anything so risky, because we'll see much, much less good software at the end of the day.

Plus a culture of risk-avoidance, blame-shifting and bureaucracy-over-innovation.

I even feel the breath of having Ada (the language) enforced over all of us again, and similar ideas...

(Not that Ada is so bad as a language, it's more about the ideas of enforcement and top-down control...)

Re: Glibc getaddrinfo stack-based buffer overflow

#429

Post by Mikushi »

TazeTSchnitzel wrote: post #330
avian wrote: post #26

Earlier quoted context omitted.

> It is time for the bimonthly Internet security meltdown. Time for the bimonthly Hacker News hour of C and C++ hate.

Which is quite justified, as with more modern programming languages, these sorts of bugs are much less likely to happen.

Are they? We have no way to know as no modern language has the reach and widespread usage of something like C.

As much as I'd like to think Rust is a nice option for the future, everything leads me to believe that if it ever gets as widespread as C you will have the same caveats, because the main issue is not the language but the programmers using it.

No amount of hand holding and safety will prevent bad practices from being used when they prove efficient in one way or another (laziness is a real killer).

Re: Glibc getaddrinfo stack-based buffer overflow

#430

Post by kimundi »

102030485868 wrote: post #47
rtpg wrote: post #18

Are there any big efforts to rewrite glibc in something like rust? ... Is that a thing that is even possible? An in-place replacement library for dynamic or static linking. I'm really worried that I still hear about buffer overflows in this day and age. Of all the libraries in the world, glibc should probably be written in some subset of Idris that compiles into 100% safe C. We have the technology to move to this now

I'm not sure how likely that'll be. It's definitely possible, but I think there are going to be a few hurdles. The main one being, symbol versioning. This is important if you export multiple symbols for a function, that is, have a program that depends on a specific implementation of a function. That could mean you depend on different versions of the same library ("functionname@@VERSION_1, functionname@@VERSION_2"), o…

The default name mangling of Rust library symbols is already kinda versioned because it includes a hash of the library, so two different versions of a library can coexist at the same time.

As far explicitly using the symbol versioning scheme you mentioned, you can do it with an attribute today:

https://play.rust-lang.org/?gist=92be155702d53c6411b2&versio...

(Disclaimer: I haven't actually compiled this as a dynamic library and checked, but its what that attribute is for, and the names seem to be used verbatim in the ASM output)

Post reply on HN