6 ms·

Restricted Shells: Sometimes Persuasive but Usually Fallacious

32 points by twakefield 8y ago

schoen 8y ago
Restricted shell escapes are a common topic in CTFs and they can be a very interesting test of one's knowledge of shell and Unix details. It's not clear to me whether people who commonly construct these challenges think that a restricted shell can actually be safe or not. (It's clear that to attempt to have a safe restricted shell, you have to, among other things, whitelist rather than blacklist executable programs, studying each one individually to learn whether it allows arbitrary code execution or not.)
- lvh 8y ago
  It also doesn't help that when some people say restricted shell they mean "actually like bash, running on a real system", or more of a debugging console (a bespoke REPL a la Python's stdlib's cmd module). I'd happily believe you can secure something like the latter, and I don't think it's worth the expense of securing the former. (But also, if you give people an anodyne shell like that, what's the point? If all you can do is peek and poke at metrics then maybe you just wanted better instrumentation?)
verdverm 8y ago
From the article: > Another form of system hardening you can use is containers. Let's not forget the 8k+ vulns on the top ten docker images, and the general security implications of containers. Like, let me run my data export from inside the publicly downloaded container that connects to the database and hasn't been locked down, because who actually audits and hardens their containers or manually configures their docker runtime?
- lvh 8y ago
  Where does the post tell you to do that? If anything it tells you a) spend a lot of time paying attention to what sounds like what you might call "the general security implications of containers" and b) it also tells you that systems like K8s mean that you may not need to run said container to your prod database. Saying that one of the senior engineers at Gravitational "is unaware of the general security implications of containers" is a pretty bold claim.
  - verdverm 8y ago
    Under alternatives, Containers and Schedulers, 3rd section from the end
    - old-gregg 8y ago
      I think he's saying "stop trying to getting shell on your production hosts and use APIs provided by container orchestrators like Kubernetes". Which makes perfect sense because those APIs have a proper, granular security model with RBAC, etc.
    - lvh 8y ago
      There's no "Containers and orchestration" section, but there's a "Containers and Schedulers" which is what I assume you meant. Here's the full text of that section: ---- Once you have a containerized application, you can use a container scheduler like Kubernetes or Docker Swarm to run it on your production hosts. Container schedulers provide a well defined API to access the status of the container like its state and logs. This means users only have access to the running programs over a well defined API. Because containers are self-contained images with everything they need to run, developers do not need access to production hosts to debug issues. For example, a good workflow allows developers to spin up a cluster locally on dummy data they control. However within production they would only have access to logs. This way data exfiltration is prevented because direct access to data is simply not allowed. ---- I read that as saying "no, don't run random containers to attach to prod, instead rely on orchestration to get you logs and instrumentation". Or is the entirety of your argument "containers are bad because images are full of vulns"?
      - verdverm 8y ago
        I'm not saying containers are bad, I use them everywhere. They require the same audit and lockdown that the host system needs. If the container accesses data, and the container has vulns, then we still have to deal with situation 1, malicious actors. From the article: > Another form of system hardening you can use is containers.
LukeShu 8y ago
The article claims that things like Bash's restricted mode are ineffective. It gives the example: parent$ bash --restricted child$ cd .. bash: cd: restricted child$ pwd /home/rjones child$ bash grandchild$ cd .. grandchild$ pwd /home where the escape is that 'child' was able to create the non-restricted shell 'grandchild'. If you think that properly configuring a restricted bash shell is a simple as executing `/bin/bash --restricted`, then you need to read the manual. The restricted shell can execute arbitrary programs in $PATH; to deploy a restricted Bash shell, you'll need to construct a PATH with whitelisted programs that it is safe to execute. The restricted Bash cannot adjust PATH, and it cannot execute programs outside of PATH. Something like: $ PATH=/etc/restricted-bin bash --restricted where /etc/restricted-bin contains symlinks to or stub-wrappers for programs that the restricted shell should be able to use.
- russjones 8y ago
  Maybe I did not provide the best example, but the point I was driving at is that the restrictions here are at the application level and not at the system level. If you take the approach you are taking, similar to ForceCommand, you have to make sure none of the commands in your PATH allow code execution. For example git, vim, less, awk, and find, all of which I use on a daily basis, can all be used to re-launch a restriction free bash. Once you remove all the commands you have to, how much of a shell do you have left?
  - LukeShu 8y ago
    > but point I was driving at is the restrictions here at the application level and not at the system level. Your point is well-taken! I'm obviously not privy the the conversations you've had with potential customers, so I'm not entirely sure what they're asking for. But (IMO) the way to think of a restricted shell is to think of it as a shell that can't do anything, except for a small list of narrowly defined tasks. Thinking of it as a normal full shell, with "unsafe" things disabled, that's a losing game, as you note.
- gruez 8y ago
  sounds like a weaker version of chroot, in the sense that it's possible to escape if you can get any of the whitelisted programs to run an arbitrary command.

32 points by twakefield 8y ago

Restricted shell escapes are a common topic in CTFs and they can be a very interesting test of one's knowledge of shell and Unix details. It's not clear to me whether people who commonly construct these challenges think that a restricted shell can actually be safe or not. (It's clear that to attempt to have a safe restricted shell, you have to, among other things, whitelist rather than blacklist executable programs, studying each one individually to learn whether it allows arbitrary code execution or not.)

lvh 8y ago
It also doesn't help that when some people say restricted shell they mean "actually like bash, running on a real system", or more of a debugging console (a bespoke REPL a la Python's stdlib's cmd module). I'd happily believe you can secure something like the latter, and I don't think it's worth the expense of securing the former. (But also, if you give people an anodyne shell like that, what's the point? If all you can do is peek and poke at metrics then maybe you just wanted better instrumentation?)

verdverm 8y ago

From the article: > Another form of system hardening you can use is containers. Let's not forget the 8k+ vulns on the top ten docker images, and the general security implications of containers. Like, let me run my data export from inside the publicly downloaded container that connects to the database and hasn't been locked down, because who actually audits and hardens their containers or manually configures their docker runtime?

lvh 8y ago
Where does the post tell you to do that? If anything it tells you a) spend a lot of time paying attention to what sounds like what you might call "the general security implications of containers" and b) it also tells you that systems like K8s mean that you may not need to run said container to your prod database. Saying that one of the senior engineers at Gravitational "is unaware of the general security implications of containers" is a pretty bold claim.
- verdverm 8y ago
  Under alternatives, Containers and Schedulers, 3rd section from the end
  - old-gregg 8y ago
    I think he's saying "stop trying to getting shell on your production hosts and use APIs provided by container orchestrators like Kubernetes". Which makes perfect sense because those APIs have a proper, granular security model with RBAC, etc.
  - lvh 8y ago
    There's no "Containers and orchestration" section, but there's a "Containers and Schedulers" which is what I assume you meant. Here's the full text of that section: ---- Once you have a containerized application, you can use a container scheduler like Kubernetes or Docker Swarm to run it on your production hosts. Container schedulers provide a well defined API to access the status of the container like its state and logs. This means users only have access to the running programs over a well defined API. Because containers are self-contained images with everything they need to run, developers do not need access to production hosts to debug issues. For example, a good workflow allows developers to spin up a cluster locally on dummy data they control. However within production they would only have access to logs. This way data exfiltration is prevented because direct access to data is simply not allowed. ---- I read that as saying "no, don't run random containers to attach to prod, instead rely on orchestration to get you logs and instrumentation". Or is the entirety of your argument "containers are bad because images are full of vulns"?
    - verdverm 8y ago
      I'm not saying containers are bad, I use them everywhere. They require the same audit and lockdown that the host system needs. If the container accesses data, and the container has vulns, then we still have to deal with situation 1, malicious actors. From the article: > Another form of system hardening you can use is containers.

LukeShu 8y ago

The article claims that things like Bash's restricted mode are ineffective. It gives the example: parent$ bash --restricted child$ cd .. bash: cd: restricted child$ pwd /home/rjones child$ bash grandchild$ cd .. grandchild$ pwd /home where the escape is that 'child' was able to create the non-restricted shell 'grandchild'. If you think that properly configuring a restricted bash shell is a simple as executing `/bin/bash --restricted`, then you need to read the manual. The restricted shell can execute arbitrary programs in $PATH; to deploy a restricted Bash shell, you'll need to construct a PATH with whitelisted programs that it is safe to execute. The restricted Bash cannot adjust PATH, and it cannot execute programs outside of PATH. Something like: $ PATH=/etc/restricted-bin bash --restricted where /etc/restricted-bin contains symlinks to or stub-wrappers for programs that the restricted shell should be able to use.

russjones 8y ago
Maybe I did not provide the best example, but the point I was driving at is that the restrictions here are at the application level and not at the system level. If you take the approach you are taking, similar to ForceCommand, you have to make sure none of the commands in your PATH allow code execution. For example git, vim, less, awk, and find, all of which I use on a daily basis, can all be used to re-launch a restriction free bash. Once you remove all the commands you have to, how much of a shell do you have left?
- LukeShu 8y ago
  > but point I was driving at is the restrictions here at the application level and not at the system level. Your point is well-taken! I'm obviously not privy the the conversations you've had with potential customers, so I'm not entirely sure what they're asking for. But (IMO) the way to think of a restricted shell is to think of it as a shell that can't do anything, except for a small list of narrowly defined tasks. Thinking of it as a normal full shell, with "unsafe" things disabled, that's a losing game, as you note.
gruez 8y ago
sounds like a weaker version of chroot, in the sense that it's possible to escape if you can get any of the whitelisted programs to run an arbitrary command.