Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SHA-3 Buffer Overflow

mouha.be

Post reply on HN
Print view View original

121–130 of 186 posts

Re: SHA-3 Buffer Overflow

#121

Post by saagarjha »

adev_ wrote: post #117
manholio wrote: post #114

Earlier quoted context omitted.

Just another nail in the long overdue C/C++ coffin. If not even these experts can get it right, under the best development conditions, public review and highest stakes, on a relatively small component with the most strict specifications, then no one can.

> Just another nail in the long overdue C/C++ coffin C, f**ing C. By the sake of god. Not C++. Stop to put both in the same basket, it just show you do not know what you are talking about. https://github.com/XKCP/XKCP/commit/fdc6fef075f4e81d6b1bc383... Something like that in modern C++ would have been done using std::span and that prevents this kind of out-of-bound access and the party-time that comes with it.

C++ offers safer constructs but they have their own sharp edges and you have to actually use them to get their benefits. In security critical software these can still be enough to cause significant problems.

Re: SHA-3 Buffer Overflow

#122

Post by boardwaalk »

adev_ wrote: post #117
manholio wrote: post #114

Earlier quoted context omitted.

Just another nail in the long overdue C/C++ coffin. If not even these experts can get it right, under the best development conditions, public review and highest stakes, on a relatively small component with the most strict specifications, then no one can.

> Just another nail in the long overdue C/C++ coffin C, f**ing C. By the sake of god. Not C++. Stop to put both in the same basket, it just show you do not know what you are talking about. https://github.com/XKCP/XKCP/commit/fdc6fef075f4e81d6b1bc383... Something like that in modern C++ would have been done using std::span and that prevents this kind of out-of-bound access and the party-time that comes with it.

Mmmhm. Go look in the docs for std::span and see how long it takes to find "The behavior is undefined if idx is out of range" or similar. For example: https://en.cppreference.com/w/cpp/container/span/operator_at

Re: SHA-3 Buffer Overflow

#123

Post by saagarjha »

galangalalgol wrote: post #67
tinglymintyfrsh wrote: post #55

Earlier quoted context omitted.

There is unlikely ever to be a perfect, but a getting better by constraining behavior that breaks things. Throw all of the compile-time, profiling, checked builds, and binary-level tools at projects for defense-in-depth and checklists, no matter the platform or the application. Fuzzing, valgrind, gperftools, dtrace, {[amt],ub}san, etc. and formal methods like seL4 if you can afford the investment. :>

Does valgrind add anything to asan given the same unit tests? I haven't used in years because it is so slow.

Address sanitizer is not precise and can miss certain classes of bugs that Valgrind would catch.

Re: SHA-3 Buffer Overflow

#124

Post by hot_gril »

Cthulhu_ wrote: post #118
hot_gril wrote: post #107

Earlier quoted context omitted.

But that'll probably run in chunks. Not gonna load 4GB into memory. Edit: Turns out there was another comment like this, and a response was that the file could be mmap'd.

You're optimistic, which is commendable, but unfortunately a naive implementation would probably just read it all. I probably would, because the happy path doesn't deal with 4 GB inputs.

I guess if your test machine always has a lot of contiguous* free memory or you never test it with a large enough file. Otherwise, it's impossible to ignore. One large download, and it wouldn't just be slow, it'd not work at all.

* Which is usually much harder than just free mem. I recall macOS always being able to give a huge chunk of memory, I guess by rearranging on the fly, but it's very slow if you ask for a lot. And Linux just says no.

Re: SHA-3 Buffer Overflow

#125

Post by kevingadd »

hot_gril wrote: post #124
Cthulhu_ wrote: post #118

Earlier quoted context omitted.

You're optimistic, which is commendable, but unfortunately a naive implementation would probably just read it all. I probably would, because the happy path doesn't deal with 4 GB inputs.

I guess if your test machine always has a lot of contiguous* free memory or you never test it with a large enough file. Otherwise, it's impossible to ignore. One large download, and it wouldn't just be slow, it'd not work at all. * Which is usually much harder than just free mem. I recall macOS always being able to give a huge chunk of memory, I guess by rearranging on the fly, but it's very slow if you ask for a lot…

It doesn't need to be contiguous on any modern operating system I'm aware of. You just need 4gb of free contiguous address space, which virtually every 64-bit application will have.

Re: SHA-3 Buffer Overflow

#126

Post by eterevsky »

adev_ wrote: post #117
manholio wrote: post #114

Earlier quoted context omitted.

Just another nail in the long overdue C/C++ coffin. If not even these experts can get it right, under the best development conditions, public review and highest stakes, on a relatively small component with the most strict specifications, then no one can.

> Just another nail in the long overdue C/C++ coffin C, f**ing C. By the sake of god. Not C++. Stop to put both in the same basket, it just show you do not know what you are talking about. https://github.com/XKCP/XKCP/commit/fdc6fef075f4e81d6b1bc383... Something like that in modern C++ would have been done using std::span and that prevents this kind of out-of-bound access and the party-time that comes with it.

Code like that in C++ would probably be over-optimized and would skip boundary checks, exposing it to the same problem.

Re: SHA-3 Buffer Overflow

#127

Post by hot_gril »

kevingadd wrote: post #125
hot_gril wrote: post #124

Earlier quoted context omitted.

I guess if your test machine always has a lot of contiguous* free memory or you never test it with a large enough file. Otherwise, it's impossible to ignore. One large download, and it wouldn't just be slow, it'd not work at all. * Which is usually much harder than just free mem. I recall macOS always being able to give a huge chunk of memory, I guess by rearranging on the fly, but it's very slow if you ask for a lot…

It doesn't need to be contiguous on any modern operating system I'm aware of. You just need 4gb of free contiguous address space , which virtually every 64-bit application will have.

Oh, then I ought to try my experiment again sometime. Last time was 8 years ago on Ubuntu Server, and maybe I'm missing a detail, like unknowingly running a 32-bit OS. But yeah the behavior you describe is more what I'd expect.

Re: SHA-3 Buffer Overflow

#128

Post by [deleted] »

Donckele wrote: post #104

“I’ve also shown how a specially constructed file can result in arbitrary code execution, ” Ouch, thats not looking good for a reference implementation for a piece of software deployed on billions and billions of machines that was written by experts and reviewed (and modified) by even bigger egg heads.

[deleted]

Re: SHA-3 Buffer Overflow

#129

Post by turminal »

hot_gril wrote: post #106
Donckele wrote: post #104

“I’ve also shown how a specially constructed file can result in arbitrary code execution, ” Ouch, thats not looking good for a reference implementation for a piece of software deployed on billions and billions of machines that was written by experts and reviewed (and modified) by even bigger egg heads.

At least it's not SHA-2, which is probably more widely used. Or am I mixing them up?

You are correct, SHA-2 is much more prevalent.

Re: SHA-3 Buffer Overflow

#130

Post by hasa »

It may be dumb question, but is there any realistic use case to use this vulnerability to reveal SHA-3 hashed secrets? Or is it just that attacker can crash systems with suitable input?
Post reply on HN