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

[monkyyy]

On Thursday, 31 July 2025 at 23:27:42 UTC, H. S. Teoh wrote:
> 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

~~I think these are extremely contrived, passwd is the os's 
responsibly and I expect all oses have it behind root 
permissions; also backups~~

swapping toStringz to option 2 then?

I think adr's FilePath may come from stealing code from rikki, 
and in thoery what rikki is suggesting is I call 
`File(FilePath("foo"))` I didnt like figuring it out; I wont 
actually store a filepath, I will write string then do whatever 
the error messages and instinct says will make the code I wrote 
compile

If `"passwd\0hi".toStringz == &"passwd__NULL__DONT_DO_THAThi"[0]` 
it wont match `passwd`; whats the `file(filepath)` abstraction 
gaining over option 2 or 3