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

401–410 of 480 posts

Re: Glibc getaddrinfo stack-based buffer overflow

#401

Post by reality_czech »

AsyncAwait wrote: post #243
djsumdog wrote: post #230

Earlier quoted context omitted.

All this "Let's replace everything with Rust" is extremely childish. Be wary of making programming languages a religion. The Java zealots did it, and you can see the results where full Java projects are used in places where a 20 line Python script would have been easier. If you're serious, one of your pet projects should be trying to implement BSD sockets with Rust. Then try compiling some C apps against your impleme…

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 language software get programming language zealots exited. So maybe you should reflect.

Re: Glibc getaddrinfo stack-based buffer overflow

#402

Post by dh997 »

djsumdog wrote: post #230
jimrandomh wrote: post #9

> "The glibc DNS client side resolver is vulnerable to a stack-based buffer overflow when the getaddrinfo() library function is used. Software using this function may be exploited with attacker-controlled domain names, attacker-controlled DNS servers, or through a man-in-the-middle attack." > "The vectors to trigger this buffer overflow are very common and can include ssh, sudo, and curl. We are confident that the ex…

All this "Let's replace everything with Rust" is extremely childish. Be wary of making programming languages a religion. The Java zealots did it, and you can see the results where full Java projects are used in places where a 20 line Python script would have been easier. If you're serious, one of your pet projects should be trying to implement BSD sockets with Rust. Then try compiling some C apps against your impleme…

The overall goal of reducing deployed LOC, complexity and low-level boilerplate is laudable and doable so by using a C isomorphic linking language (can call into and can call from) to gradually, experimenting by converting one module at a time and increasing tempo of semver API refactorings for also reducing code and features to the essentials. "The journey of a thousand miles begins..."

Also, we need more unit testing, fuzzing and formally proven correct libraries (a-la seL4). Most C development is really bad about unit testing and fuzzing because it's incredibly laborious and verbose, even when it's known to be a good idea.

Re: Glibc getaddrinfo stack-based buffer overflow

#403

Post by dh997 »

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…

Oracle JVM/OpenJDK and .net CLR are deployed in production at basically every profitable company on Earth.

PHP... Is deployed because it's perceived to be easier and friendlier than other religions, and so wins with that popularity war (as MySQL did). Facebook HHVM is another approach. Folks know the likely warts and mitigate to shrink the attack surface by defending deeply from front layers down to backend services.

Postgres was harder to use in the 2000's despite having a clean codebase but got mucb easier to use, in large part due to MySQL, while leading on features inspired by Oracle DBMS and more recently NoSQLs with hstore.

Attacking popularity for what gets the job done is moot because defense is never ending vigilance for anything real.

Perhaps the focus should be on starting to formally-verifying core libs like zlib, OpenSSL, OpenSSH (portable), glibc, etc. for correctness and resilience against side-effects and ABI promises.

Re: Glibc getaddrinfo stack-based buffer overflow

#404

Post by dh997 »

tkinom wrote: post #212
ploxiln wrote: post #180

Earlier quoted context omitted.

Or perhaps he made a more subtle point: you can't replace all C with Rust. Even if you rewrite the libc (you'll need some assembly), even if you rewrite the kernel (you'll need a lot of assembly and "unsafe"), there will still be lots of closed-source C running on undocumented components of your computer as firmware. C is just representative of computers as they really are today, for a bunch of reasons (mostly pragma…

Agree. "C" to OS, Kernel, Computer Language, applications is like oxygen is to life on earth. Yes, O2 causes fire from time to time, but you can't live without it.

The analogy is wrong because most all languages are Turing complete, and therefore equivalent despite paradigm and feature differences. The main reason seL4 was written in Haskell and again in C was to cross-verify behavior. C might be legacy ubiquitous, however it doesn't have to be the last word in shared library development by any means.

Any language which has a toolchain which produce flat binaries or use link scripts to specify sections can potentially be used for kernel and os dev. Bonus points for a toolchain which can compile itself.

There are kernels written entirely in Rust with some assembly glue. Others are writing production embedded domain-specific OSes in Haskell, OCaml, etc. for real, mission-critical systems right now and have been doing so for the last 5-10 years.

C inherently or inadvertently leads to giant codebases and subtle bugs when used too liberally, as opposed to higher-level, statically-compiled languages like Haskell and others.

The main issue with legacy code is how we choose to either keep investing effort in putting fingers into the levees or try something new in an incremental fashion.

PS: I would like to see Go get with it and support non-usermode, self-hosted and embedded development without including a giant, hard-to-port runtime in everything.

Re: Glibc getaddrinfo stack-based buffer overflow

#405

Post by spc476 »

alkonaut wrote: post #345
AndyKelley wrote: post #341

Earlier quoted context omitted.

Compare to the musl implementation: http://git.musl-libc.org/cgit/musl/tree/src/network/getaddri...

It's better. The musl version is slightly smaller and tidier but also doesn't handle all the same proticols so it's not a fair comparison. At least it doesn't have a lot of conditional compilation and macros. But the musl code too has bloody ZERO comments for a nearly 100 line long method of dense/opaque C code! Why? Is commenting and splitting code into functions frowned upon in "traditional" systems programming? Wh…

As long as the function is doing one thing conceptually, I don't see the benefit of breaking it up into multiple routines just because it's too long (for some arbitrary length). Not only do you have the cognitive overhead of trying to come up with a name [1], but passing in all the required parameters to the function. And for this function, I personally don't see any good "breaking points".

At work, I have to deal with a code base where code is split up like that, and it's a royal pain to follow, and the resulting functions aren't usable by anything else.

[1] The two hardest problems in computer science is cache invalidation, naming things, and off by one errors.

Re: Glibc getaddrinfo stack-based buffer overflow

#406

Post by PuercoPop »

pcwalton wrote: post #293
PuercoPop wrote: post #284

Earlier quoted context omitted.

I agree with the general sentiment: "There are no silver bullets, only tradeoffs." However I disagree that that is the issue at hand. At the very least the trade off is on the wrong side of the equation, it is computers that should do stuff like bound checking not humans. P.D. It irks me that Rust slogan is 'zero cost' abstraction. There is definitely a cost. The memory model is more complex than C. One shouldn't try…

Well, the term "zero cost" is just borrowed from C++, where it means exactly the same thing: more expressiveness, more features, and a higher learning curve with no runtime performance cost. But I do agree with you that there is a learning curve, and some things that are more easily expressible in C are not as easily expressible in Rust (and vice versa). It's undeniable that writing a doubly linked list from scratch…

I am aware that it comes from C++. 'Excesive Marketing' is something that seems to pervade through software, not trying to single out Rust. I think 'zero runtime cost abstraction' would be a small improvement for the slogan.

Re: Glibc getaddrinfo stack-based buffer overflow

#407

Post by cyphar »

dh997 wrote: post #404
tkinom wrote: post #212

Earlier quoted context omitted.

Agree. "C" to OS, Kernel, Computer Language, applications is like oxygen is to life on earth. Yes, O2 causes fire from time to time, but you can't live without it.

The analogy is wrong because most all languages are Turing complete, and therefore equivalent despite paradigm and feature differences. The main reason seL4 was written in Haskell and again in C was to cross-verify behavior. C might be legacy ubiquitous, however it doesn't have to be the last word in shared library development by any means. Any language which has a toolchain which produce flat binaries or use link sc…

> The main reason seL4 was written in Haskell and again in C was to cross-verify behavior.

seL4 was modeled in Haskell, then written in C. Then they used tools to verify that the Haskell models matched the C code.

Re: Glibc getaddrinfo stack-based buffer overflow

#408

Post by spc476 »

gpderetta wrote: post #163
lmm wrote: post #117

Earlier quoted context omitted.

The JVM looks to have its own implementation. I imagine .net would be the same. There's ocaml-dns for unikernel-deployed OCaml. A managed language generally doesn't give you direct access to syscalls at all. In rust you can perform them without having to go via C.

Note that DNS lookup doesn't require any syscall other than normal socket i/o, which is available on any non toy language. One possible reason why java might implements its own name resolution is because it wants to do async name resolution which is not possible (at least portably) via getaddrinfo and friends.

Yes, but you still need to encode the questions and decode the answers. Existing libraries that do this are pretty dismal.

(Dismal enough that I ended up writing my own DNS encoding/decoding library (https://github.com/spc476/SPCDNS) with the aim of being easy to use as well as safe. It assumes nothing about the incoming packet and does extensive validation (enough that it found bugs in other DNS libraries). It also avoids dynamic memory allocations. It's used at work in two projects that get heavy use (millions of DNS queries a day) and so far has performed without incident, so well written C code is possible.)

Re: Glibc getaddrinfo stack-based buffer overflow

#409

Post by rphlx »

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

FYI, that will pretty much break DNSSEC.
Post reply on HN