When your API is "running shell commands"



  • Saw this today and I decided to see the proposed fix.
    :headdesk:



  • A classic case of "I don't know how to properly escape strings so I'll just filter the problematic character".



  • If I designed an operating system, I'd make it as hard as possible to implement the C standard library system() function, probably by making sure there was no standard shell or command line of any kind. (Of course, you could always emulate a shell in your favorite shell emulator, but it wouldn't be doing any system() calls)


  • BINNED

    ...

    onyx@jarvis ~> sudo aptitude remove --purge cinnamon-desktop-environment && \
                   sudo aptitude install xfce4-session
    

    Filed under: Not really, but I'm seriously considering it


  • area_deu

    @Onyx said:

    seriously considering it

    You might want look for unguarded / insufficiently guarded shell calls before that ...



  • int system (const char* command); - Invokes the command processor to execute a command.

    The description says it all: invokes the command processor. Processing implies parsing, interpreting... stuff that doesn't belong in the standard library IMO, leave it to bash, csh, or your CLI of choice.

    Sadly Linux is kind of built entirely around that concept.



  • A couple years ago we solved a bunch of performance by implementing rm -rf and cp in our own code instead of shelling out - TR :wtf: is probably that there aren't library functions for those.



  • @LB_ said:

    If I designed an operating system, I'd make it as hard as possible to implement the C standard library system() function, probably by making sure there was no standard shell or command line of any kind.

    Hm. Why does that sound familiar to me...

    Maybe because the second-most-popular OS in the world for about 15 years was exactly that.


  • BINNED

    Amazing, this is first time I search for a Python module to import and use for groupadd and there is none! First search in Google suggests an SO answer using sub-process and shell out. If only the developer had searched Google once, and heeded sub-process advice there from 2009.

    So it is the SO answer's fault for not including an easily copy-pasta with sub-process :)



  • @PleegWat said:

    A couple years ago we solved a bunch of performance by implementing rm -rf and cp in our own code instead of shelling out - TR :wtf: is probably that there aren't library functions for those.

    http://www.boost.org/doc/libs/1_59_0/libs/filesystem/doc/reference.html#remove_all ?



  • That's C++. We're on plain old C, and at the time that was C89 (though C99 standard library functions were OK somehow).



  • What's the reason for using C and not C++? Portability? (I'm not saying there aren't valid reasons, I'm just curious)



  • It was in C before I got here. I only have the most rudimentary knowledge of C++ myself, so I have no idea what the cost/benefit would be of converting it. I do know the current code doesn't compile as C++ - we have several widely-used struct members named 'try'.



  • At least you're running in an application context. Now, let me introduce you to xp_cmdshell, which is basically a system() call from SQL Server.

    So any SQL injection is automatically a potential shell elevation, if you run with that enabled. And AFAIK there are no named parameters for this thing, you need to use string concatenation...



  • What's the attack vector here?

    To execute this, you probably need to input root password beforehand. And if you get that far, why not start a console and do whatever you want as root?

    I mean, it's a WTF, but I don't see an immediate threat here.



  • It's less about security and more about allowing any characters in that field that the user wants.



  • Yeah, but now others are cropping up that are much more serious. https://github.com/linuxmint/Cinnamon/issues/4658



  • While I agree that Linux desktop developers are incompetent at designing a good UI now they are incompetent at writing good code as well. I'm always surprised how idiotic many developers are when they handle user input.



  • @gravejunker said:

    Yeah, but now others are cropping up that are much more serious. https://github.com/linuxmint/Cinnamon/issues/4658

    How is that one more serious? Seems even less likely to be exploited.



  • Because now someone can just create a file $(rm -rf ~).jpg?



  • @gravejunker said:

    Because now someone can just create a file $(rm -rf ~).jpg?

    OK, you're right, that makes more sense.

    User would still have to select that image in the desktop background dialog box, but it's a genuine risk.


  • BINNED

    @cartman82 said:

    To execute this, you probably need to input root password beforehand. And if you get that far, why not start a console and do whatever you want as root?

    Yeah, it's dangerous if you leave your computer unattended during the time when the keyring manager will still let you execute stuff as root without a password prompt.

    Speaking of, wasn't there an applet on Gnome2 at least that let you just click it and revoke permissions immediately? I'm sure I saw it somewhere and it was enabled by default. Why don't we have stuff like that any more?



  • @LB_ said:

    If I designed an operating system, I'd make it as hard as possible to implement the C standard library system() function

    If I managed a project and found coders using os.system() instead of os.execl() to invoke groupadd or groupmod, there would be harsh words spoken in the code review meeting.

    Calling a command interpreter from inside something else is only very rarely useful, and usually a source of trouble. If you know what executable you need to invoke, and you have a bunch of strings to pass to it as arguments, then not only is calling it via one of the os.exec*() family safer than doing it via os.system(), it's easier. Gluing all your arguments together into a single command line just so that a shell can take them apart again before handing them off to the program you actually need is just backasswards and dumb.



  • If you really want to emulate system(), you can do exec.Command("sh", "-c", "file -bi \"$(rm -rf ~).jpg\"").Run()



  • @cartman82 said:

    User would still have to select that image in the desktop background dialog box

    Nope, they would just have to open its folder.



  • @ben_lubar said:

    If you really want to emulate system()

    The Bad Ideas Thread is :arrows:


  • Discourse touched me in a no-no place

    @hifi said:

    While I agree that Linux desktop most developers are incompetent

    FTFY. I can remember the bad old days when Outlook's security strategy for dealing with untrusted files could be described as “throw it over the wall”, just asking the OS to Open whatever the file was. If it was executable, that was cool.

    I don't know if there was any auto-open behaviour with that, but there was a time when this sort of thing caused huge problems. And all because one (common) mail client had a security-critical step written by a knuckle-dragging moron, probably because the OS had a convenient API available for doing it that way.



  • @PleegWat said:

    the cost/benefit would be of converting [C to C++]

    high/marginal, unless you built an object system in C, in which case high/moderate.



  • Needs more cinnamon_real_escape_command().


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.