Can someone explain in layman's terms how will this affects me as a Linux user who works on Ubuntu?
Update your machines and you should probably restart too so any running processes link to the new libc.
Glibc getaddrinfo stack-based buffer overflow
141–150 of 480 posts
Re: Glibc getaddrinfo stack-based buffer overflow
#142[flagged]
There absolutely are some silver bullets. ALL of these buffer overflows in C happen because the C stack grows backward, and old space is after new space. If anyone have enough of a crap just to standardize a calling convention that went the other way, stack buffer overwrites would ALWAYS go into unused memory. Then security-minded people would switch to this calling convention for secure programs, and many problems w…
Not really, no. The very first modern stack overflow exploit (Lopatic's NCSA HTTPD) targeted HPPA, where the stack grows up.
Re: Glibc getaddrinfo stack-based buffer overflow
#143Earlier quoted context omitted.
Every engineering decision has costs as well as benefits. It's the same reason soldiers only wear heavy armour in the centre of their chests and backs. Why don't we armour the rest? Because the cost outweighs the benefits ... and the tooling (i.e. medevac and modern medicine) makes up for the deficits.
>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.
Are fucking serious? Have you built anything significant?
This is a very empirical view, not a superstition. If you want to learn more about this, and aren't just trolling look at the development of the A4 Skyhawk, the lunar lander, the space shuttle ... hell, any well documented large system.
I wish I could reach through the internet and smack you in the head for such a stupid comment.
Re: Glibc getaddrinfo stack-based buffer overflow
#144Earlier 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…
C is still the lingua franca; it's the only toolchain you can rely on a target system having, and the only real usable interface for calling between code in different languages. So my theory is that it's not so much that people are especially inclined towards starting projects in C, but that projects in C have fewer barriers to distribution and thus adoption. By natural selection, C code spreads and becomes standard;…
This is exactly my reason for starting a couple of recent side-projects in C. You can pretty much count on the target system having an ANSI C compiler (even rather old systems), which can't be said for any other language. Have an ANSI C compiler? Great! You don't need anything else to build and install this program. You don't need to install a hefty runtime like the JVM and you don't need to know what a gem is.
I don't think I'm immune to the hazards inherent in the language. I try my best be aware of them and to write safe code, and still find myself introducing a segfault now and then. Luckily, tools like valgrind and Coverity can really help to catch these kinds of issues early (of course, they can't catch everything, but I've been amazed by just how much they do catch).
Re: Glibc getaddrinfo stack-based buffer overflow
#145Can we agree that it's urgently necessary to rewrite most of the core Linux/OSS stack in memory safe languages? Exploits like this come up all the time, and we know how to completely eliminate them. I don't care if it's Rust or D or Go or Haskell or OCaml or anything else, as long as it's not C. The sooner we do this, the better.
"It'll be slower than C", they'll say. However, I would gladly sacrifice performance for memory safety, at least in an alternate, opt-in, network stack. Unfortunately, I doubt this will ever happen while Linus is around. He seems to be quite fond of C. I assume he would argue this is a matter of shitty developers, not a shitty language.
[deleted]
Re: Glibc getaddrinfo stack-based buffer overflow
#146Earlier quoted context omitted.
>Patch ASAP What exactly do you patch? Say you have a TCP server, written in Python or in Go. Do you have to update Python and Go ASAP then and recompile the Go server? Custom compiled Apache, Nginx? Recompile those? That's a lot of work..
If you have dynamically linked libc (which you should), you only need to upgrade libc and restart all network processes. [Does anyone know if systemd in pid1 calls getaddrinfo? If so, this is another good reason for a minimal pid1, as you will need to reboot]
you need to restart all processes that might do a network address lookup. That's pretty much every daemon.
Re: Glibc getaddrinfo stack-based buffer overflow
#147[flagged]
There is no silver bullet, but can we at least stop aiming the gun at our own foot?
Re: Glibc getaddrinfo stack-based buffer overflow
#148Earlier quoted context omitted.
>Patch ASAP What exactly do you patch? Say you have a TCP server, written in Python or in Go. Do you have to update Python and Go ASAP then and recompile the Go server? Custom compiled Apache, Nginx? Recompile those? That's a lot of work..
You patch glibc. Everything else is dynamically linking it.
I think it's possible to statically link glibc in Go, but I don't recall the particular compiler incantations offhand.
Re: Glibc getaddrinfo stack-based buffer overflow
#149Earlier quoted context omitted.
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.
No I think he meant that if you adhere to certain language constructs the language is just as memory safe as Rust/others.
Eg. Don't use C++ as C with vectors, use C++ with the more modern language features:
It's the difference between:
// where f is of type fstream of a file containging "this is a string\r\n"No I think he meant that if you adhere to certain language constructs the language is just as memory safe as Rust/others.
It's the difference between:
std::string A = "ab" + std::string("c");
// And:
char Buffer[512] = {};
strcat(Buffer, "ab");
strcat(Buffer, "c");
std::vector SomeData = { 1,2,3 }
std::vector OtherData(SomeData.begin(), SomeData.end());
// and:
std::vector SomeData = { 1,2,3 }
std::vector OtherData;
OtherData.reserve(3);
memcpy(...)
std::string A = "ab" + std::string("c");
// And:
char Buffer[512] = {};
strcat(Buffer, "ab");
strcat(Buffer, "c");
std::vector SomeData = { 1,2,3 }
std::vector OtherData(SomeData.begin(), SomeData.end());
// and:
std::vector SomeData = { 1,2,3 }
std::vector OtherData;
OtherData.reserve(3);
memcpy(...)
Re: Glibc getaddrinfo stack-based buffer overflow
#150Earlier quoted context omitted.
Sometimes there isn't any other choice. For example, in the mobile OS space if you want to write native apps, without rewriting 100% of the application code per platform and avoid toolchain debugging headaches, C and C++ are the only languages available in iOS, Android and WP SDKs. In WP case, there are APIs like DirectX that aren't fully exposed via WinRT, so you need to write a C++ wrapper for those type of APIs. T…
Isn't slapping C onto objective C trivial for iOS and OSX? Just wrap to the GUI's objective C. You can use this trick for WTL on Window's C++, too.
People seem to forget that Objective C is a superset of C. No slapping on required. You're already writing it. Avoid brackets and a few other things and it's C.
You don't even have to rename .m to .c, but you can.