Date: Tue, 27 Feb 2024 23:49:41 +0000
Protecting sensitive memory (such as it might contain passwords), it is definitely valuable, the problem however is the details.
As far as I'm aware most operating systems already protect access to memory assigned to other applications, if it isn't than a fix should be done at the OS level.
As far as C++ standard is concerned, this proposal would only make sense if you mean protect access to memory assigned within the same application from another section that has gone rogue.
Let's say you designate a piece of memory intended to store passwords. How would you prevent the application from accessing it when in parts "when the access is illegitimate" while still allowing access "when the access is legitimate"? And how would you be able to tell between the two when the execution has been hijacked?
There are ways to do hardening at the level of the operating system. But I'm not sure if there's anything that can be done at the application level, and to that extent, if there's anything that can be done at the C++ language level. I suspect that there might be things that you can do to make it harder, but not full proof.
I would be curious to know if someone has an answer.
-----Original Message-----
From: SG14 <sg14-bounces_at_lists.isocpp.org> On Behalf Of Robin Rowe via SG14
Sent: Tuesday, February 27, 2024 6:24 PM
To: undefined-behavior-study-group_at_sei.cmu.edu; sg14_at_lists.isocpp.org
Cc: Robin Rowe <robin.rowe_at_heroicrobots.com>
Subject: [SG14] Memory Safety and Page Protected Memory
https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/press-release-technical-report/
Memory safety concerns seem focused on the undefined behavior of pointers on buffer overruns and out-of-bounds memory accesses. However, not all memory is equally unsafe. Unintended access to memory that contains a password or an exec() command is much more valuable to hackers. Hacking of passwords is of particular concern for financial systems.
C/C++ programs use stack, heap or static memory to hold data. Any of these can be overrun. I am experimenting with code to add a fourth category, page memory. That is, allocation creates a memory region that cannot be overrun into or out of because it is an isolated protected page in memory. The default behavior for an overrun is a segfault.
Is this a good or bad idea? Been done before? Thoughts?
Robin Rowe
Beverly Hills, California
*Chairman ISO WG21 SG14 C++ Banking and Financial Systems Subcommittee _______________________________________________
SG14 mailing list
SG14_at_[hidden]p.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg14
As far as I'm aware most operating systems already protect access to memory assigned to other applications, if it isn't than a fix should be done at the OS level.
As far as C++ standard is concerned, this proposal would only make sense if you mean protect access to memory assigned within the same application from another section that has gone rogue.
Let's say you designate a piece of memory intended to store passwords. How would you prevent the application from accessing it when in parts "when the access is illegitimate" while still allowing access "when the access is legitimate"? And how would you be able to tell between the two when the execution has been hijacked?
There are ways to do hardening at the level of the operating system. But I'm not sure if there's anything that can be done at the application level, and to that extent, if there's anything that can be done at the C++ language level. I suspect that there might be things that you can do to make it harder, but not full proof.
I would be curious to know if someone has an answer.
-----Original Message-----
From: SG14 <sg14-bounces_at_lists.isocpp.org> On Behalf Of Robin Rowe via SG14
Sent: Tuesday, February 27, 2024 6:24 PM
To: undefined-behavior-study-group_at_sei.cmu.edu; sg14_at_lists.isocpp.org
Cc: Robin Rowe <robin.rowe_at_heroicrobots.com>
Subject: [SG14] Memory Safety and Page Protected Memory
https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/press-release-technical-report/
Memory safety concerns seem focused on the undefined behavior of pointers on buffer overruns and out-of-bounds memory accesses. However, not all memory is equally unsafe. Unintended access to memory that contains a password or an exec() command is much more valuable to hackers. Hacking of passwords is of particular concern for financial systems.
C/C++ programs use stack, heap or static memory to hold data. Any of these can be overrun. I am experimenting with code to add a fourth category, page memory. That is, allocation creates a memory region that cannot be overrun into or out of because it is an isolated protected page in memory. The default behavior for an overrun is a segfault.
Is this a good or bad idea? Been done before? Thoughts?
Robin Rowe
Beverly Hills, California
*Chairman ISO WG21 SG14 C++ Banking and Financial Systems Subcommittee _______________________________________________
SG14 mailing list
SG14_at_[hidden]p.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg14
Received on 2024-02-27 23:49:44