Why are browsers able to execute other programs?

Discussion in 'other security issues & news' started by Gullible Jones, Sep 13, 2014.

  1. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,461
    Or create threads in other programs? Or debug other programs? etc. etc.?

    This functionality being available is all part of the DAC model, but it could be overridden internally with stub functions, couldn't it?

    e.g.

    Code:
    #include <unistd.h>
    int execve(const char *filename,
    	char *const argv[],
    	char *const envp[])
    {
    	return 0;
    }
    
    On Linux this can be compiled into a library and injected into programs at load time using LD_PRELOAD. The program then won't be able to launch other programs, because it doesn't see the real execve() provided by the kernel.

    Sure, there are ways of overriding this override. Even so. Why don't applications that don't need exec. debug, etc. functionality override the necessary functions in their headers? Wouldn't that raise the bar a bit on what was required to compromise a typical desktop?
     
  2. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    5,067
    Probably developers don't want to make their software to inconvenient. Most of them still need to execute other programs (update checkers...). So they will have to somehow whitelist those applications. At the end they would probably have to built whole anti-exe logic in their software. IMO anti-exe is better implemented on OS level than on application level.
     
  3. Keatah

    Keatah Registered Member

    Joined:
    Jan 13, 2011
    Posts:
    853
    ..because it makes it easier to load ads and to transfer money from your wallet to their wallet. Ughhh...
     
  4. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    Well, this factors into it. This policy alone does little, as an attacker can override that, or do plenty of other things.

    But, on Linux there's seccomp filters, which would prevent an execve call if you filtered it out.

    The thing is that browsers need those things you're talking about. Firefox needs to be able to launch and communicate with your torrent program when you download a torrent file, and open it within the browser. Things like that require exactly the type of permissions you find in DAC - arbitrary access to other programs.
     
  5. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,461
    ... Wait, duh. Even without exec privileges you can write an executable/library somewhere, and make sure it will get executed/loaded later. ("export LD_PRELOAD=~/.config/.libnasty.so" in your ~/.xprofile, or whatever.) So this really would be trivial to circumvent. N/M.

    Anyway I'm not in the habit of launching stuff directly from my browser, but maybe other people are, I don't know.

    Seccomp is a step in the right direction though. The typical DAC model of programs inheriting all the user's privileges = broken, IMO.
     
  6. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    Or just do what fork does anyways, load up a process and execute it. You could just overwrite your browsers address space with another image. I've been meaning to try this anyways.

    DAC's really good for some things, and really clearly broken for many others. Just like MAC. Some things just aren't going to make sense in an apparmor profile, or SELinux for that matter. And some things are.

    That's why there's a lot of different methods for access control on Linux. Read my blog :p
     
  7. wat0114

    wat0114 Registered Member

    Joined:
    Aug 5, 2012
    Posts:
    1,984
    Location:
    Canada
    Anyways on Linux is it not easy enough with Apparmor (MAC), for instance, to restrict the browser to interact with only what is required and no more, with exacting precision?
     
  8. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    Well, not without losing some functionality.

    So when you download a .deb package in Chrome, you can click it and it'll start to install via the package manager. Thta's a nice functionality for most people.

    But the problem is that that is obviously dangerous behavior.

    So Apparmor could allow Ux on the software-center but then that's a huge hole and makes the whole profile a bit useless.

    So you either get security or usability with Apparmor.

    The nicer approachis brokered, which is what chrome does, where it'll only send that .deb pcakage to the software-center if it knows it makes sense to do so.
     
  9. wat0114

    wat0114 Registered Member

    Joined:
    Aug 5, 2012
    Posts:
    1,984
    Location:
    Canada
    Oh okay. Does there have to be involvement from the browser to install the package?
     
  10. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    Well, no. If you want to install it from just clicking the download in your browser, it does. But if you click from the folder it dowlnoaded too then it's not handled by the browser.
     
  11. wat0114

    wat0114 Registered Member

    Joined:
    Aug 5, 2012
    Posts:
    1,984
    Location:
    Canada
    That makes sense and what I thought was the case. I guess I'm just thinking about typical browsing and something, let's say a malicious script, on an exploited webpage attempts to somehow, someway, utilize the browser in one of the attack steps, and this is where a tightly restricted Apparmor profile should prevent this from happening.
     
  12. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    Scripts shouldn't be too dangerous in regards to an apparmor profile. They can only work within the confines of the renderer, and this is the case in any browser. The issue is more when the script is able to gain control over the renderer, and then a sandbox is helpful.
     
  13. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    I believe that Google Chrome on Windows uses job objects (operating system feature) to stop certain Chrome processes from launching other programs.

    On Windows, you can use RunInsideLimitedJob to do this with whatever processes you want to.
     
  14. wat0114

    wat0114 Registered Member

    Joined:
    Aug 5, 2012
    Posts:
    1,984
    Location:
    Canada
    This pdf document seems to be referencing that, at least with regards to the sandbox...

    -http://seclab.stanford.edu/websec/chromium/chromium-security-architecture.pdf

     
  15. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    8,038
    Location:
    The Netherlands
    Yes exactly, isn´t it true that all apps can act like a "parent process"? That´s the way that Windows is designed. I do know that a while back, the Maxthon browser had this feature that could white-list certain apps that could be launched (the "external utilities" feature) while all others are blocked. In theory that could have stopped certain type of exploits.

    @ wat0114

    When you read the document (about the Chromium sandbox), you can also get an idea of how Sandboxie works, quite interesting. :)
     
  16. wat0114

    wat0114 Registered Member

    Joined:
    Aug 5, 2012
    Posts:
    1,984
    Location:
    Canada
    Thanks, I'll read it more thoroughly when I get a chance. Just so busy these days :)
     
Loading...