[flagged]
How many of the ridiculous Ruby security issues were memory-safety ones like this one?
Glibc getaddrinfo stack-based buffer overflow
81–90 of 480 posts
Re: Glibc getaddrinfo stack-based buffer overflow
#82[flagged]
Remote code execution occurs in one of exactly two ways.
- eval/exec() of untrusted turing-complete code
- memory unsafety
There are strange machines and logic vulnerabilities, which as you're aware are pitfalls present in all languages, and can be very subtle. But these are not the same as executing arbitrary operations with all the privileges of the process. This is something we can end today, and Rust would suffice to do it, and can be deployed in many of the same situations as C.
The primary second-system problem with Rust is lack of a stable ABI and upgradable dynamic linking story (e.g. for generics which are effectively inlined even across shared library boundaries), which makes it impossible to upgrade shared libraries. That's a serious problem, which needs to be addressed if Rust is going to improve security for the world outside of the "we static-link 50MB of libraries" Web browser space.
Re: Glibc getaddrinfo stack-based buffer overflow
#83Earlier quoted context omitted.
> Java FTW on Android This made me smile. Need I point out that Android runs on top of Linux? Or that you can still use C/C++ on Android? http://developer.android.com/tools/sdk/ndk/index.html
... and apple runs of top of BSD. C popularity pre-dates workstations. DEC (Digital Equipment Corporation ) , maker of popular mini computers, used it extensively.
I only bothered to use C when forced into UNIX world via Xenix.
Yes Apple runs on top of BSD, because they weren't able to write a new OS and had to buy one, which happened to be built on top of BSD.
Once upon a time they had their OS written in Object Pascal, but then they decided to rewrite it in C to welcome those UNIX devs.
Nothing prevents them to rewrite parts of the OS in Swift after the language gets more mature.
It is only a question of willingness, political will and money.
Re: Glibc getaddrinfo stack-based buffer overflow
#84Can someone please explain the fix in practice? Is it as simple as upgrading glibc (and eglibc?) on all servers? Or is there a network change I should immediately change?
Re: Glibc getaddrinfo stack-based buffer overflow
#85Are 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
It would be a wasted effort. Anything that's using glibc (directly) is written in C and therefore inherently unsafe. There are only two kinds of programs written in C: those that need to do unsafe things and those whose developers don't care about safety. Better to look to building systems that don't need to run any C code (see the recent fuss around unikernels).
> Anything that's using glibc (directly) is written in C
... and together with stuff using glibc (indirectly) constitutes 99.99% of your software.
How much software/languages implement their own DNS resolver instead of just calling libc? How about syscall wrappers?
Re: Glibc getaddrinfo stack-based buffer overflow
#86As far as I see the bug primarily lies within this function here... resolv/res_send.c https://github.com/bminor/glibc/blob/master/resolv/res_send.... Lines 952 ... 1389 [=~450 lines of code], with more than a dozen of variables holding random state. Think about the complexity you have with all the conditionals and loops, often copying and pasting similar conditions with (xx1 && xx2) variants. While discusions about t…
You sure can prove that any correct code does something correct, but you can never prove something about a program outside of a machine-checked formal proof.
Re: Glibc getaddrinfo stack-based buffer overflow
#87Buffer overrun on the stack...this makes me sad. It's 2016.
Re: Glibc getaddrinfo stack-based buffer overflow
#88Earlier quoted context omitted.
Rust is actually a decent contender in this space. Memory safe and with the performance of C. > I assume he would argue this is a matter of shitty developers, not a shitty language. All developers are shitty.
Rust is not a decent contender. It is far too immature. The only reasonable contender is C++.
C++ is not reasonable if your goal is to avoid memory safety bugs.
Re: Glibc getaddrinfo stack-based buffer overflow
#89> "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…
Does rust use getaddrinfo()?
grep -irn getaddrinfo .
./src/libstd/sys/common/net.rs:123: try!(cvt_gai(c::getaddrinfo(c_host.as_ptr(), ptr::null(), ptr::null(),
./src/libstd/sys/windows/c.rs:1235: pub fn getaddrinfo(node: const c_char, service: const c_char,
./src/libstd/sys/windows/net.rs:69:/// Provides the functionality of `cvt` for the return values of `getaddrinfo`
How many places doesn't rust source code use C structures or call C APIs?
In the rust source tree, run this:
grep -irn '[^a-zA-Z0-9]c::' . |wc
615 3143 56000
279 1719 23448Re: Glibc getaddrinfo stack-based buffer overflow
#90Earlier quoted context omitted.
I'm still unsure why people start projects with C, or C++ (or other unsafe languages), that do not need it. I totally understand that there are use cases where C++ and C make sense. In my mind, these use cases are quite limited though - integration into 3rd party libraries, legacy codebases, and working in embedded environments. I also agree that performance can be a reason, but see Knuth's opinion on premature optim…
Written properly, C++ is not unsafe. Certain language own certain domains, for better or worse, this means that most developers interested in low level programming will know C/C++, and that the will be a substantial amount of tooling already in place.
> Written properly, C++ is not unsafe.
This is abusing what "unsafe" means. As a language, C++ is inherently unsafe. However, some C++ programs ("written properly") are correct.
If written properly C++ is not unsafe, then written properly C is not unsafe.