boostorg
Security Vulnerability: Security Descriptor NULL DACLs
Came across this one while viewing old TRAC bugs. It's pretty recent and I assume the poster didn't know to put it here (and they are anonymous) so... here's the text:
Our security team has flagged: if(SetSecurityDescriptorDacl(&sd, true, 0, false)) in interprocess\detail\win32_api.hpp as a "high-priority" vulnerability
They then reference some of the text from the C6248 warning which says in part:
Objects that have null DACLs can have their security descriptors altered by malicious users so that no one has access to the object.
Even if everyone needs access to an object, the object should be secured so that only administrators can alter its security. If only the creator needs access to an object, a DACL should not be set on the object; the system will choose an appropriate default.
Looks like this could be fixed with a little research if someone was available to do the work.
This vulnerability allows anyone to have access to the content of the shared memory. One potential solution is for the library to overload the creation functions (the ones that create the mapped file) so they receive a path with an existing file. If the file does not exist or the specific operation (read or write or both) cannot be performed it will throw. This way users are responsible for security which they achieve by assigning ACLs to the file. It is hard for the library implementer to try to provide portable ways to assign ACLs to files and/or folders within the library.
The Microsoft docs say in part, If a Windows object does not have a ... (DACL), the system allows everyone full access to it. This is contrasted elsewhere with a "null DACL", which is a DACL set with a null pointer (what Interprocess is doing). As I understand it, a null DACL also gives full access, but allows the access to be changed ("can have their security descriptors altered", per the docs).
Could the solution be as simple as removing the call to SetSecurityDescriptorDacl, so that there is no DACL (instead of a null DACL)?
If you can change the DACL an attacker can too :-) . The library offers permissions that can be used when creating files. Setting permissions in a platform dependent way is allowed. I guess this could be a solution for many use cases.