6 ms·
Yet another example of why command-line interfaces are not safe. Can we start to use something other than arrays of null-terminated strings for input?
by TazeTSchnitzel 10y ago
Yet another example of why command-line interfaces are not safe. Can we start to use something other than arrays of null-terminated strings for input?
- madez 10y agoWhat alternative do you propose?
- TazeTSchnitzel 10y agoI don't have an easy one. If you can do things in-process, a shared library means type safety. But I don't know what the best practice for IPC (which this is essentially a form of) is.
- throwawayish 10y ago- Structured data instead of always somewhat wonky text formats - Request-reply -- Acknowledge stuff. Especially when it's security relevant - For security relevant stuff, don't just silently fail or fall back to some idiot default. Eg. say a command message for setting a password doesn't contain the password field -- then fail the request, don't assume an empty password. (Ie. be liberal about what you accept but not too liberal)
- tinus_hn 10y agoYou shouldn't be liberal at all if security is a concern. You should be strict, use a well defined format and refuse anything that doesn't comply. It isn't difficult to be strict so being liberal is just asking for trouble uselessly.
- lmm 10y agoI propose protocol buffers or equivalent.
- marcosdumay 10y agoThere are some streams of binary data there too... It's not THAT bad. That's why everybody is still using it. But there are many better options, since the CLI, eg. people have created distributable libraries, and network APIs. Yet, changing APIs will break any of them.
- zython 10y agoCLI- as opposed to what ? What other option is there that is easier and safer to implement ?
- arpa 10y agopowershell approach comes to mind - you just pass objects.
- pjmlp 10y agoActual libraries.
- SixSigma 10y agoAnd then someone wraps it in a CLI interface. What you need is a kernel that exposes programs as a file system like plan9
- pjmlp 10y agoThat is what the REPL like on Lisp Machines, Interlisp-D, Smalltalk, Mesa/Cedar, Oberon is for.
- deleted 10y ago[deleted]
- RandomOpinion 10y ago>What you need is a kernel that exposes programs as a file system like plan9 Powershell?
- zeveb 10y agoBut if it's a C library then there are memory issues, buffer overflows, undefined behaviour — everything that's bad about C. The right thing IMHO would be to use pipes & stdin/stdout/stderr, but with a well-defined machine interface.
- 10y ago
- peterwwillis 10y agoThere is no "safe" standard, but command line is primarily designed for users, not applications. It almost by definition requires extra scrutiny. But the issue here was not the command line. It was not handling the interface properly. Somebody wrote a 5 minute hack to handle security functionality and probably didn't even read the application source to look for proper use, much less version checking. The same thing happens with APIs. And null terminated strings have worked for 40 years, that doesn't have anything to do with this.
- Sir_Cmpwn 10y agoThis is a breaking API change. The fact that the API was consumed over the CLI is irrelevant, the actual problem is that there was an API and it broke.
- TazeTSchnitzel 10y agoAre you sure? Would this not manifest differently if it were, say, a function call?
- Sir_Cmpwn 10y agoWell, it might cause a compile error if the function changed. Unless you're using a dynamic language, of course.
- EdHominem 10y agoDifferently, yes. Better, unlikely. Unless you've got a password type and a regular string type, how's the compiler to know you've swapped the password with a config string? Joel on Software wrote an interesting article that's related to this, oddly about Hungarian notation. His point was that *lwistrp = "foo" tells you meaningless stuff (lwip and str) about your data. That's what the compiler is supposed to track. But 'u_pw' and 's_pw' (unsafe/safe) for pre and post-processed user-input tells you something meaningful the compiler has a harder time tracking. (Not impossible with taint-tracking, but ...) The relevance is that types tend to be based on the implementation details instead of the higher-level facts. For this sort of function to be actually safe, not just compiler-safe, it would need higher-level types and to be compiled into your language (not called via an opaque FFI) to check them.