niedz., 31 sie 2025 o 01:09 Oliver Hunt via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
>
>
> > On Aug 30, 2025, at 9:29 AM, Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> wrote:
> >
> > On Friday, 29 August 2025 18:23:20 Pacific Daylight Time Oliver Hunt via Std-
> > Proposals wrote:
> >> Yes - and if you used a std::array, or a std::span, or a std::vector, or
> >> many other types - with the hardened runtime option, sigh - it would
> >> correctly fail without a security vulnerability.
> >
> > I'd argue that a denial-of-service by causing the hardened checkers to trip
> > and halt the application is also a security vulnerability.
>
> Yes, bugs in software are bad.
>
> There is no case where guaranteed termination is worse than non-guaranteed termination.
>
> Very simply: if you have a bug that with the hardened runtime causes a DoS on your service,
> and a DoS is a security vulnerability, then an attacker can cause a DoS if they want to, without
> the hardened runtime because the whole purpose of the hardened runtime is making the
> failure happen immediately, rather than allowing an attacker to control the point of the failure.
>
> I am getting very tired of these arguments about “immediate termination is a security/safety
> vulnerability” because it completely fails to understand that if you have a bug that results in
> termination, the bug can be made to cause termination anyway.
>
> The best case scenario for a bug in your code, in which the hardened runtime causes an
> immediate failure, is that an attacker can also create a DoS using the same bug. i.e the best
> case scenario for not using the hardened runtime is security _parity_.
>
> Of course that is the absolutely best case: in reality without the hardened runtime, the bug in
> your code can be used to do far far more that a DoS: it can be used by the attacker to read
> or write data into your process, which can be leveraged to exfiltrate data, or to take complete
> control of the system - and then as we have seen repeatedly, extending that control into
> access to other systems that are connected.
>
> There is literally no case where an immediate termination is worse than not terminating.
>
> The reverse is not true.
>

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.

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.

This means adding hardened will make the first week after deploy hell
as future bugs will materialize
at the same time. This is a good thing in the long term but this can
be very painful in the short term.

> —Oliver
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals