Hacker News new | ask | show | jobs
by comex 1967 days ago
> I would agree that that's more arguably a bug in libc than in doas, but also note that the startup code for any language has to consider this case.

This is true, but for a language where dynamically sized arrays are a standard data type, the most natural thing to do is to start by collecting the arguments into an array (maybe copying the strings at this point, maybe not). All further argument parsing is done with the array and is thus bounds-checked. I checked Rust's standard library and sure enough, it follows this pattern. Though, I could imagine some hypothetical startup code messing up the argc=0 case if it tried to separate argv[0] from the rest of the arguments while constructing the array.

> Anyway, I like your comment, but I'd recommend a different moral to this story: in the space of 47 minutes you were able to conduct a reasonably thorough audit on the doas codebase. Wanna give that a shot for sudo now?

Fair point. (And I didn't downvote you.) But in my opinion, that just confirms my view: ideally you want both simplicity and memory safety.

1 comments

Aye, I agree. But if we consider that case, a similar mistake could be made: hard-coding argv[0]. The result is different, in that the program just aborts, but it's still the Wrong Thing To Do, and in both cases it never leads to anything exploitable. Bugs are bugs, no matter what language. We could come up with examples all day. Just head to your nearest Rust program's bug tracker :)
Aborting when argv[0] doesn't exist... is a perfectly reasonable thing to do? Someone called the program with arguments severely out of spec, crashing is fine.
It's actually within spec, in this case. Still reasonable?
It's within the C and systemv abi specs, but it's not within the implicit contract of how you call command line programs. I'm fine with it.
Right, but if it was within the specs, possible to craft a scenario for, and leads to a security vulnerability, then does it suddenly matter? A bug is a bug. If it doesn't matter for Rust then it doesn't matter for C.
> and leads to a security vulnerability

I have trouble imagining how aborting leads to a security vulnerability? That's literally running no code, the opposite of running arbitrary code.

Aborting is fine in any language. Criticisms of C here would come about because C doesn't abort when it should (null pointer deref, array out of bounds, etc), not the inverse.