std.file functions and embedded NUL characters [CWE-158]

[H. S. Teoh]

On Thu, Jul 31, 2025 at 10:27:56PM +0000, monkyyy via Digitalmars-d wrote:
> On Thursday, 31 July 2025 at 21:47:24 UTC, Richard (Rikki) Andrew Cattermole
> wrote:
> > This is quite a good example of why for PhobosV3 I want us to go
> > through a FilePath abstraction, rather than accepting random strings
> > for file names.
> 
> whats wrong with just changing toStringz? I dont understand the threat
> profile imagined by the infinitely wise cve org; but you could make
> toStringz:
> 
> a) shorten it to the first null char
[...]

This is precisely what it currently does, and where the problem is.
Consider: you have user input specifying a filename, and your code
checks to make sure it doesn't overwrite a file it's not supposed to.
As a contrived example, say you prohibit "/etc/passwd" as a filename.
Now what happens when the user inputs "/etc/passwd\0ha_you_missed_me" as
filename?  The OS considers the NUL as the end of the filename, so your
user gets access to "/etc/passwd" after all.

Another example: maybe you have a database management program and your
user specifies a filename to save the database, and you keep an AA of
previously-used names which you check, so that the user doesn't stomp
over another user's database file.  Now consider what happens if user A
inputs "database\01.db" and user B inputs "database\02.db".  The OS
considers the NUL as the end of the filename, so user A's file is
actually "database", and so is user B's file, so user B can now
overwrite user A's data.

These are just some mild cases.  I'm pretty sure if you think hard
enough, you'll be able to come up with something that will open a
security hole by exploiting the fact that what the D code thinks is the
filename is different from what the OS thinks is the filename.


T

-- 
May you live all the days of your life. -- Jonathan Swift