Date: Sun, 31 Aug 2025 03:58:48 -0700
> 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.
> 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.
> 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] <mailto:Std-Proposals_at_[hidden]>
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>
> 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.
> 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.
> 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] <mailto:Std-Proposals_at_[hidden]>
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2025-08-31 10:59:00