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

[Steven Schveighoffer]

On Tuesday, 5 August 2025 at 02:47:22 UTC, kdevel wrote:
> On Sunday, 3 August 2025 at 21:01:05 UTC, Steven Schveighoffer 
> wrote:
>> [...]
>> The issue is going to be fixed, not sure if you saw my issue 
>> report. It's quite an easy fix actually.
>
> Thanks but sorry I could not yet take a look.

TL;DR: We can fix `tempCString` since we are always copying the 
whole thing. So the issue is moot at that point.

>> But just so you know, C also allows passing in C strings with 
>> embedded null characters:
>>
>> ```c
>> #include <unistd.h>
>>
>> int main() {
>>    rmdir("hello\0world");
>>    return 0;
>> }
>> ```
>
> On the one hand there is no such thing as a C string with 
> embedded `NUL` (because the `NUL` terminates the string).
>
> On the other hand the `rmdir` function takes `const char 
> *pathname`. Your code contains an array argument 
> (`"hello\0world"`). According to C's rules this array decays 
> into a pointer *before* `rmdir` is invoked. Thus one can hardly 
> say that a string with embedded `NUL` is passed to the function.

C does not give me an error for this code. Regardless of what it 
"technically" is doing, you have the same issue there -- C does 
not warn you or error on this concern. So it is identically 
vulnerable to your test case.

>> And we do expose `core.stdc.posix.unistd`.
>
> Yes. But in the D-function in question is `std.file.rmdir`.

C already needs to caution people not to call this function with 
embedded null string array. D can also do the same thing. My 
point is, I don't imagine we need to "fix" the unistd binding.

Again, who's responsible for verification is a tradeoff. In this 
case, we have an obvious answer for std.file.rmdir, because we 
can fix `tempCString`. But it also could be solved by just 
identifying what happens if you pass in such a string, and put 
the onus on the user to check.

-Steve