441–450 of 480 posts
Is there something that can be done about this on the network level? I mean, it seems almost impossible to assure that every instance of getaddrinfo is patched. I'm thinking about a background tool (iptables plugin?) that simply truncates long DNS replies, so that they can never cause a buffer overflow.
See https://news.ycombinator.com/item?id=11112923 on this page.
> "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…
How did I know this would turn into a C vs Rust debate
* Is Google Public DNS a potential mitigator? Sub-thread at https://news.ycombinator.com/item?id=11113113 .
* Is Google Public DNS a potential exploit vector? Sub-thread at https://news.ycombinator.com/item?id=11111300 .
* Are there any BIND settings that are potential mitigators? Sub-thread at https://news.ycombinator.com/item?id=11110646 .
* What happens if one's DNS proxy server doesn't itself support sending >2048 byte answer messages to the BIND DNS client library in the first place? Sub-thread at https://news.ycombinator.com/item?id=11111617 .
* How exploitable is this? What about Windows? Sub-thread at https://news.ycombinator.com/item?id=11110443 .
* What about MacOS 10? Sub-thread https://news.ycombinator.com/item?id=11113471, and a mention of BSD libc at https://news.ycombinator.com/item?id=11111702 .
If I understand the Google sec article correctly, this requires a single packet > 2048 bytes to be received by a host using glibc.
> The vulnerability relies on an oversized (2048+ bytes) UDP or TCP response, which is followed by another response that will overwrite the stack.
Is my understanding correct?
If it is, then it's worth pointing out that many links on the public Internet have an MTU of 1500 bytes. This is an historical legacy of original Ethernet from the 80's. Path-MTU-Detection(PMTUD) doesn't really work on the Internet, so it's safest to assume that you only ever get 1500 bytes.
Given all that, this places a burden on anyone wanting to eploit this. Since they cannot assume a PMTU greater than 1500 bytes between endpoints, they're limited in how they can exploit the bug. Correct?
Please correct me if I'm wrong. I always feel these bug reports are missing that vital piece of information I need to operationalize the bug. And thanks.
Earlier quoted context omitted.
Neither is Rust, which comes with a huge RTS that itself likely full of such bugs. The library and the compiler too may have bugs that compromise the "guaranteed" memory safety of a libc written in Rust. There is no silver bullet here. If one takes into account all the sources of bugs, C may very well be the best choice given its maturity and its ecosystem. Our best bet is likely to put more resources towards glibc d…
Rust does not really have an RTS per se. libstd is just a standard library. Also, even if rustc has soundness bugs, you won't find them if you don't look for them, and even then, just trying to make your program fit the types will prevent most bugs. By the way, glibc's code is too horrible to be read - musl is a more modern alternative.
And if you don't want to use the standard library, you just say #![no_std] https://doc.rust-lang.org/stable/book/using-rust-without-the...
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…
Have you looked at CCured? http://www.cs.berkeley.edu/~necula/Papers/ccured_pldi03.pdf "CCured is a program transformation system that adds memory safety guarantees to C programs by verifying statically that memory errors cannot occur and by inserting run-time checks where static verification is insufficient."
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…
Are you arguing that since we can't replace everything with safe code, we shouldn't replace most of it? Security is not a binary state. Even taking firmware into account, if you compare the number of CVEs affecting "normal code" and firmware, the choice is trivial.
Well, yes, the effort to replace even a small part of current code base with something perceived as "safe code" is huge. The re-factoring effort is so great that there is no doubt a significant number of new seurity problems wouldn't be created.
They would of course be different kind of problems. Not indexing errors, perhaps, but something we don't even know about. And justifiying this very large cost is not so easy.
I have a question that hopefully someone can clear up for me. If I understand the Google sec article correctly, this requires a single packet > 2048 bytes to be received by a host using glibc. > The vulnerability relies on an oversized (2048+ bytes) UDP or TCP response, which is followed by another response that will overwrite the stack. Is my understanding correct? If it is, then it's worth pointing out that many li…
Redhat (RHEL5 unaffected) - https://access.redhat.com/security/cve/cve-2015-7547 - https://access.redhat.com/articles/2161461 RHEL6 - https://rhn.redhat.com/errata/RHSA-2016-0175.html - update to glibc-2.12-1.166.el6_7.7.x86_64.rpm RHEL7 - https://rhn.redhat.com/errata/RHSA-2016-0176.html - update to glibc-2.17-106.el7_2.4.x86_64.rpm Debian - https://security-tracker.debian.org/tracker/CVE-2015-7547 Use "aptitude sho…
Ubuntu - http://people.canonical.com/~ubuntu-security/cve/2015/CVE-20...
Also, why is all this important and useful information scattered all over the place? Ubuntu people, if you're reading, on this page: http://packages.ubuntu.com/trusty/libc6 I think you should have a history of updates to the package, and which security vulnerabilities it covers, with a link back to the above linked page. Looking at this page, looking at my system, looking at the news, I kind of have no idea what's going on.
I was going to complain that this people.canonical.com CVE page should also be linked from some sort of Ubuntu security bulletin, but I googled first and found that that's exactly where it's linked from. Still, I somehow reckon I would have never thought of that if not for this conversation. It should perhaps be linked from the packages page, though I'm not a UX guy, maybe that would just add confusion. But, this CVE page, with the domain "people.canonical.com", linking to launchpad pages, it doesn't look like it's made for users. You could make some improvements to make it more user friendly like the packages page. You could make it explicit: "Here's the packages you need to upgrade. here's the command to run to upgrade your whole system. Here's the command to upgrade just this package." As it stands, this doesn't even tell you what binary packages to get (libc6, I think? I'm still not even sure!), this just lists the source package (glibc). And, change "DNE" and "pending" to indicators that are more clear to us. Or, make a new page if this one is not meant for users.
For security stuff (not just Ubuntu by any means), all sorts of useful information is scattered all over the place. To name a few questions that I never determined clear answers to:
* What about this Android MMS attack that was supposed to be catastrophic and so easy to mount, that supposedly like half of all Android users are still vulnerable to? We've not heard of a single actual exploit in the wild. Where's some sort of official source downgrading its severity?
* If the libpng thing was such a fiasco, why were there no updates in Ubuntu for so long? Did it turn out not to be such a serious attack vector? Where's the documentation on that determination?
* For heartbleed: I recall having to poke around looking at the "built on" date for my openssl packages to see whether I was upgraded or not. That's not an acceptable state of affairs.
I'm not looking for answers to these particular questions now, I'm just wondering, why do we all have to rely on rumors and advice from random people in discussion forums for this stuff? There's a recent trend of understanding that improved UX can improve security (Signal, etc). Here's a good place to make some improvements, IMHO.
Sorry if I've come off as entitled here, it's just a source of irritation to me.
Earlier quoted context omitted.
Under certain conditions, it does not. https://golang.org/pkg/net/#hdr-Name_Resolution
When it does not it dynamically links.
Among others the page lists:
> [...] when /etc/resolv.conf or /etc/nsswitch.conf specify the use of features that the Go resolver does not implement, and when the name being looked up ends in .local or is an mDNS name.
Those things you can't check at compile time.
In any case, you can tell whether the binary is statically linked or not.
Statically linked:
$ file /usr/bin/consul
/usr/bin/consul: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped
$ ldd /usr/bin/consul
not a dynamic executable
$ file /bin/echo
/bin/echo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
$ ldd /bin/echo
linux-vdso.so.1 => (0x00007fff01fff000)
libc.so.6 => /lib64/libc.so.6 (0x0000003bcd800000)
/lib64/ld-linux-x86-64.so.2 (0x0000003bcd000000)
Earlier 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…
> Can people tell me why they start projects in ... C still? Okay. Based on my current project (Porting AVS out of shit-tier Microsoft C++). I want a region of memory in which I can treat as a bitmap and set pixels at given location to given colours. I know of no other language that gives me this block of memory to draw into. That's probably because I don't know enough. Most languages seem to tout how immutable thing…
http://www.lispworks.com/documentation/HyperSpec/Body/f_mk_a...
https://wiki.haskell.org/Numeric_Haskell:_A_Vector_Tutorial#...