niedz., 31 sie 2025 o 12:59 Oliver Hunt <oliver_at_[hidden]> napisał(a):
>
>
>
> On Aug 31, 2025, at 3:18 AM, Marcin Jaczewski <marcinjaczewski86_at_[hidden]> wrote:
>
>
>
> > But there could be rare cases where exploit can't lead to privilege escalation.
> > Image one off error in logging subsystem. You can override some parts of logs.
> > As this is writeonly, a corrupted file does not affect the rest of the program.
>
>
> There have been RCE vulnerabilities that were started by literally a single byte buffer overrun.
>
> There have been vulnerabilities that got to kernel compromise via calls to exit and abort.
>

You missed my point. Where I said it can't do that at all? I only give
examples where this is not the case.
Another situation like this would be to write to struct padding, in
most programs impossible to observe.
Simply put there are cases UB that can be benign in a specific
environment (of course it could become cancerous after some trivial
unrelated change). Something like this:
```
int foo() {}
int bar() { return 0; }
```
This code will "work" on some compilers, assembly will be right but
only as an accident.
But any change can break this easily like someone using the `-fpo`
flag or `bar` gets removed as it is not used on
higher optimization levels.

> > Another thing is ease of attack, hardening guarantee all bugged
> > requests will crash,
> > other case require weeks of analyzing what specific payload is needed
> > to exploit the vulnerability.
>
>
> No, a guaranteed termination tells you the first point at which a crash could happen, vs miscellaneous crashes all over your service that you have no way to determine the origin of. Knowing the point of failure is far far easier to deal with than random crashes all over your codebase.
>

You again miss my point. This was from the attacker perspective. You
know that request will cause memory override but not all will case
service to crash or miss behave. Because there could be other checks
that
prevent attacks. Like you can send to long string to server that will
be able to override the return pointer on the stack somewhere, but
this string must be valid utf-8 (as this is the first thing that
server does with a request).

Another case like this is that stack array have "safe" buffer:
```
Uint64 getUserPasswordHash()
{
    std::array<char, 32> login = { };
    std::array<char, 32> pass = { };
    //... it was using `login` in safe way
    gets(pass.data()); //no limit! can override `login` but its not
used here any more
    return hash(pass);
}
```
the value received `pass` does have a check but for utf code points
not bytes, this means
that you can only send 31 ASCII characters and this will be fine, but
other scripts can exceed this limit.
Users from Europe rarely exceed 40 bytes. And assembly here works
"fine" but when an attacker uses easter asian script, he can override
the return pointer.
This means many requests are bugged but only a couple can crash the system.
After hardening the majority of users will cause a crash here.

I do not deny this is a good thing, but sometimes it would require
temporary revert hardening
until this bug gets fixed. This is something similar to C++ soft from
'90 where its in many cases used
UB and work fine, but on new compilers it crashes because of that UB.

I had similar problems when I added more validations to user configs
in my program.
Before it accepted contradicting configs but somehow it still worked.
Even enforcing some basic sanity in configs break many uses and make
them unhappy
as it forces them to update things that from their perspective "worked
fine before".


To sum up, hardening is good but is not free, and its cost can be
proportional to technical debt.

> > This means adding hardened will make the first week after deploy hell
> > as future bugs will materialize
>
>
> No, it means the bugs you find in the first week do not become security vulnerabilities weeks, months, or years later, because you did not detect them in the first week. It also means that week of issues consists of issues that are much easier to fix.
>
> > at the same time. This is a good thing in the long term but this can
> > be very painful in the short term.
>
>
> Absolutely, and immediate, unexploitable crashes shortly after release are far, far better than silent errors that persist for years, and crashing at the point of error means it is much easier to actually find and fix the issue.
>
> I need to put “undetectable” in context: I once had to diagnose and incredibly high volume crash (from my point of view - we are talking very large numbers), and while actually crashing immediately upon the failure in debug builds courtesy of bounds - which I’ll note that all the code, and adjacent code, does in release builds at this point - none of the crashes provided any indication of the source of the memory corrupt. The cause could not be found until we found one person who was encountering it sufficiently frequently: actually reproducing it required doing a bunch of specific steps, and then leaving a stapler weighing down their space bar for 3 hours. Even having caught the failure, getting back to the actual place the caused the error took a long time. Terminating on a bounds check failure showed the exact location of the error immediately - it did not require hours of space bar, it required just starting the repro state and failed immediately and could provide the _line number_ of the error.
>
> There is a perception that crashing on such an error is exploitable by an attacker, but that fundamentally assumes the an attacker that can exploit “bounds checking causes termination” is not able to construct a payload that causes a termination anyway - the only reason they would not do that is because you’ve provided them with something much more powerful than instant termination.
>
> —Oliver
>
>
> —Oliver
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>