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

231–240 of 480 posts

Re: Glibc getaddrinfo stack-based buffer overflow

#231

Post by maerF0x0 »

efuquen wrote: post #189

Can someone give me technical reasons why this world isn't possible: Parts of the linux kernel or glibc or any other critical C code gets replaced by rust code little parts at a time, which is also calleable from C ( https://doc.rust-lang.org/book/ffi.html )? That way these libraries could be made safer in a controlled and incremental manner. And to reiterate I'm asking for technical limitations, not political or dog…

All code is binary, you can write a compiler that turns human readable code (rust) into binary. Then you can push that binary wherever you want (into a custom address in another file for example). Technically we can do _anything_ we can rewrite part of it in JavaScript if we want.

What you need to understand is that almost 100% of engineering is economic. Is it worth the time to rewrite things in a new language, to rebuild the tool chain to make things easy/convenient, to deal with the gotchas in each new language and their compilers ? On and on the list goes. And most of the issue is there isnt incentive, users of free software have a first mover problem in that if someone else pays for the software to be made, nonparticipants get it for free. Thus we all wait for someone else to pay for all the wonderful things that would benefit us all.

Re: Glibc getaddrinfo stack-based buffer overflow

#232

Post by alkonaut »

Criticism of C aside, when you use a language that isn't very expressive and where it's easy to shoot yourself in the foot, you need to keep it very neat.

I mean just look at this https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/pos...

That size of methods, huge macros, the low ratio of comments to (non-obvious) statements etc.

I know it's easy to criticize very old and tested code, but there is no (and never was any) excuse for code like that.

Re: Glibc getaddrinfo stack-based buffer overflow

#233

Post by mikeash »

pjmlp wrote: post #219
mikeash wrote: post #164

Earlier quoted context omitted.

I wouldn't say that UNIX workstations became truly popular until after Mac OS X took off sometime in the 2000s. C and C++ were enormously popular in the 90s, if not earlier. They were really common for Mac and Windows programming, and I don't think that had anything to do with the UNIX connection.

I was there. The only reason to get a C compiler for CP/M, MS-DOS or Amiga was to be able to bring work home from those expensive workstations at work or university.

CP/M, MS-DOS, and Amiga sound like the 80s, not the 90s. I recall that C was not super popular at that time (I arbitrarily chose to start learning Pascal around 1988, given a choice between C and Pascal, probably the wrong choice in hindsight) but by the early/mid 90s it was pretty huge.

Re: Glibc getaddrinfo stack-based buffer overflow

#234

Post by inopinatus »

weinzierl wrote: post #121

Can this be used to exploit DNS servers via other rogue DNS servers? What if I setup a rogue DNS and wait for it to be queried by 8.8.8.8. When I own 8.8.8.8 I can exploit every client that queries it. Browsers use getaddrinfo(), don't they?

No. Recursive resolvers do not use getaddrinfo(3) to resolve DNS queries.

Re: Glibc getaddrinfo stack-based buffer overflow

#235

Post by woodman »

autoreleasepool wrote: post #169
anon1385 wrote: post #129

Earlier quoted context omitted.

>Every engineering decision has costs as well as benefits. This is only true if you are superstitious or religious and believe that good things that happens to you (or humanity in general) must be balanced out by something bad happening.

That's such an irrational assertion, ironically enough. Every decision has a trade off, even non-engineering decisions. It's called opportunity cost.

> It's called opportunity cost.

The law of conservation of energy, as close to the metal as it gets. I remember reading about the same thing in terms of algorithmic complexity (in the context of data compression), and how one can only shift entropy about. Anybody got any keywords handy for practical examples? My hour of searching ended with conservation of information and black holes...

Re: Glibc getaddrinfo stack-based buffer overflow

#236

Post by mikeash »

steveklabnik wrote: post #227
mikeash wrote: post #172

Earlier quoted context omitted.

Has there been any work on a safe C? Not a C-ish language that is safe, but an actual implementation of the C language itself. The C standard doesn't require the compiler to check the validity of array indexing and pointer dereferences and such, but it also doesn't require the compiler not to. Can they be added without destroying performance and compatibility? Some of this already exists, with stuff like stack canari…

This is sort of what Cyclone tried, in a way.

Cyclone looks cool, but it's a pretty significant departure from normal C. I'm wondering how far you can take safety without changing the actual language at all. Or rather, how far you can take safety without changing the language and without completely killing performance. Memory safety shouldn't be hard: track all valid regions and pointers to them and don't allow mixing stuff up. But doing it fast is tough.

Re: Glibc getaddrinfo stack-based buffer overflow

#238

Post by steveklabnik »

autoreleasepool wrote: post #229
steveklabnik wrote: post #215

Earlier quoted context omitted.

> a kernel in Rust/Nim/whatever would be under a big unsafe block anyways? Only portions of it do. The whole point of unsafe is that you can encapsulate it, and then go from there.

Definitely. The ability to encapsulate code that is less strictly checked by the compiler is what makes Rust such a compelling alternative to C. I definitely think Rust is the ideal choice for a hobby kernel from scratch in 2016. My point is that unsafety is unavoidable. You can encapsulate unsafe Rust or wrap plain old C, it's, for all practical purposes, the same. At that level language features matter a lot less.…

Yeah, absolutely. Ultimately, the machine is not safe. Such is life.

Re: Glibc getaddrinfo stack-based buffer overflow

#240

Post by [deleted] »

woodman wrote: post #235
autoreleasepool wrote: post #169

Earlier quoted context omitted.

That's such an irrational assertion, ironically enough. Every decision has a trade off, even non-engineering decisions. It's called opportunity cost.

> It's called opportunity cost. The law of conservation of energy, as close to the metal as it gets. I remember reading about the same thing in terms of algorithmic complexity (in the context of data compression), and how one can only shift entropy about. Anybody got any keywords handy for practical examples? My hour of searching ended with conservation of information and black holes...

[deleted]
Post reply on HN