6 ms·

Unprivileged process injection techniques in Linux

161 points by joe_v 3y ago

deleted 3y ago
[deleted]
grugq 3y ago
The history actually goes back quite a bit further. Exactly 20 years ago I wrote and released userland exec(). https://seclists.org/bugtraq/2004/Jan/2 https://seclists.org/bugtraq/2004/Jan/2 Good to see that the technique is still viable after two decades. On a related note, this sort of issue (difficulty researching the origins of techniques, and hacking history in general) is a problem that will only get worse. As a community we haven’t created an institutional memory beyond “the oldest hacker you know.”
- Retr0id 3y ago
  > Good to see that the technique is still viable after two decades. It absolutely blew my mind to learn that Debian is still shipping with Yama mitigations disabled by default (last time I checked, which was about a year ago). I think they're one of the only mainstream distros to be doing this, although I haven't done a comprehensive survey.
  - deadlydose 3y ago
    I think this is so users can choose what level of restriction they want using kernel.yama.ptrace_scope with sysctl, 0 being the default and 2 being the most restrictive.
    - Retr0id 3y ago
      You can configure it on most distros, it doesn't excuse having an insecure default.
  - secure 3y ago
    The Debian patch for this setting is: https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/patches/debian/yama-disable-by-default.patch https://salsa.debian.org/kernel-team/linux/-/blob/master/deb... The decision made there is from 2013 (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712740 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712740), so it might be worth revisiting. Could you file a bug report to get the discussion started?
- fluoridation 3y ago
  Ha. I did the exact same thing on Windows to inject DLLs into Chrome once. EDIT: Geez. I sure wish I knew what's so objectionable about what I said.
  - ImPostingOnHN 3y ago
    I didn't vote either way until you edited your post to add the meta comment. I don't like posters discussing moderation of their posts (I find that discussion about themselves to be vain and distracting from the topic), and I feel gross and off topic myself talking about it even now. The chrome thing sounds cool.
    - throwaway892238 3y ago
      The strange taboos of ingroups
      - deleted 3y ago
        [deleted]
      - ImPostingOnHN 3y ago
        To be fair, the guidelines[0] request of us: > Please don't comment about the voting on comments. It never does any good, and it makes boring reading. Which, yeah. [0] – https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
        WhackyIdeas 3y ago
        Maybe one day HN will realise that giving the ability to downvote is pretty pointless and needlessly open to abuse. That negative ability just promotes negativity itself and a bloody pia when I am reading a greyed out message because I am too stubborn to go into the settings and change defaults - so I just steam on thinking HN are using a relic of an ideology.
        3y ago
- joe_v 3y ago
  Hah! I was just referencing this paper the other day when mucking with the linker for an unrelated reason. I probably should have chosen a better name for my article - I am trying to cover the cases of "you have Linux command execution, how do you run native code?" as opposed to your approach which as I understand is more: "you are running native code, how can you load a separate ELF in-process?" Agreed about institutional memory; zines/blogs are very important; but at the end of the day I usually end up just asking in some corner of IRC.
  - codethief 3y ago
    > "you have Linux command execution, how do you run native code?" I was going to ask you what the precise situation is in which you'd apply the ideas from the blog post as I don't know what exactly is meant by "process injection". I think the article would benefit from providing a little bit more background for us non-hackers / non-pentesters. Still, very interesting article – thank you! PS: The article says > you need a writable location on disk; this is not always true in e.g. read-only chroots, filesystems, containers, etc Couldn't you create a temporary file in-memory (e.g. in /dev/shm or in some tmpfs), make it executable (+x) and then execute it?
    - joe_v 3y ago
      Apologies it's a little scattered. Roughly it's about dealing with situations where you can execute a command but now want to run a native executable, and how much noise such a thing will make in the presence of monitoring. > Couldn't you create a temporary file in-memory (e.g. in /dev/shm or in some tmpfs), make it executable (+x) and then execute it? It all depends on how your environment is set up: whether a tmpfs or shm device is mounted and writable by your user is up to the admin. For example, on many embedded devices you often want to avoid writes to prevent any sort of filesystem wear, or because you have a write-once media like a ROM; so the whole fs will be mounted readonly. With chroots it's best practice to provide a minimal environment - unless tempfiles are needed there will usually not be a /tmp. Try `docker run --read-only -ti ubuntu bash` as another example: ``` root@9302f159e0e0:/tmp# touch a touch: cannot touch 'a': Read-only file system ```
- aengelke 3y ago
  Userland exec was a very interesting read when I came across it some years ago; thanks for publishing it! The technique still mostly works, but on recent glibc+Linux, you also have to unregister the rseq area before cleaning out the address space (which requires computing the address first, which is a little cumbersome). Otherwise, if the rseq area is registered but unmapped, the kernel will forcefully stop the program. (That said, nowadays memfd_create + fexecve is likely a more robust alternative in many cases.)
  - grugq 3y ago
    Yup, probably the more robust approach.
- throwaway892238 3y ago
  > we haven’t created an institutional memory beyond “the oldest hacker you know.” Which I'd wager is due to over-reliance on search engines. The net is stuffed to the brim with useless bullshit designed to steal eyeballs, so finding anything somebody published two decades ago is now impossible. Internet Archive is useful if you already know what website used to exist, not so useful if you don't. Whatever happened to that website that was a combination of blog + archive of exploit POCs? Wasn't it called PacketStorm? I just tried to find it with two search engines and came up empty. That would've been an ideal place to track down old techniques and news.
- contingencies 3y ago
  Happy opseccy new year Grug :)
  - grugq 3y ago
    Merry OPSEC, and a happy OPSEC Year!
Retr0id 3y ago
Hi, I'm the author of the `dlinject` tool referenced in the article. Sadly I haven't been maintaining it and it doesn't work on modern distros anymore - not for any fundamental reasons, it just needs some compatibility tweaks. However, it's been forked as `asminject`[1], with bug fixes and other bells and whistles. I consider it to be the latest evolution of that particular approach, and I should probably update the dlinject readme to point at it. Thank you for the writeup! [1] https://github.com/BishopFox/asminject https://github.com/BishopFox/asminject
charcircuit 3y ago
Why does Bash have permission to ptrace or read other process's memory. This should already be locked down, but I suspect it's not because for some reason a lot of systems do not use LSMs or don't care about security in general.
- khuey 3y ago
  The same bash instance is the parent of the process being attacked so it meets the requirements to ptrace at yama/ptrace_scope == 1.
  - Retr0id 3y ago
    In the case of stelf-loader, the bash instance is attacking itself. It's not especially unexpected for a process to be able to modify its own memory.
    - charcircuit 3y ago
      >It's not especially unexpected for a process to be able to modify its own memory. It is unexpected for Bash to do that so it shouldn't be given access to ptrace.
      - Retr0id 3y ago
        stelf-loader does not use ptrace
        charcircuit 3y ago
        Writing to /proc/pid/mem requires access to ptrace. I never said it would use ptrace directly.
        Retr0id 3y ago
        It's gated by the same access control logic that governs ptrace yes, but it does not use ptrace directly nor indirectly. The first step of that logic is: > If the calling thread and the target thread are in the same thread group, access is always allowed.
gavinray 3y ago
It's a bit wild, but you can use memfd_create to do things like load libraries or binaries, on a filesystem that has no read/write access and noexec enabled. I have been meaning to do a blog post about this, since it doesn't seem to be common knowledge. Originally, I thought of it as a response to a Reddit question: "How can I load a shared library from a .jar directly into memory?" https://old.reddit.com/r/java/comments/15lcwil/load_shared_lib_from_jar_directly_into_memory/jvbyu4i/ https://old.reddit.com/r/java/comments/15lcwil/load_shared_l...
- Retr0id 3y ago
  > on a filesystem that has... memfd_create's whole selling point is that it isn't backed by a filesystem; it isn't "on" one in the first place, so there is nowhere for it to inherit such restrictions from. The consequences of that can be surprising though, I agree, and are worth exploring and writing about.

161 points by joe_v 3y ago

deleted 3y ago

[deleted]

The history actually goes back quite a bit further. Exactly 20 years ago I wrote and released userland exec(). https://seclists.org/bugtraq/2004/Jan/2 https://seclists.org/bugtraq/2004/Jan/2 Good to see that the technique is still viable after two decades. On a related note, this sort of issue (difficulty researching the origins of techniques, and hacking history in general) is a problem that will only get worse. As a community we haven’t created an institutional memory beyond “the oldest hacker you know.”

Retr0id 3y ago
> Good to see that the technique is still viable after two decades. It absolutely blew my mind to learn that Debian is still shipping with Yama mitigations disabled by default (last time I checked, which was about a year ago). I think they're one of the only mainstream distros to be doing this, although I haven't done a comprehensive survey.
- deadlydose 3y ago
  I think this is so users can choose what level of restriction they want using kernel.yama.ptrace_scope with sysctl, 0 being the default and 2 being the most restrictive.
  - Retr0id 3y ago
    You can configure it on most distros, it doesn't excuse having an insecure default.
- secure 3y ago
  The Debian patch for this setting is: https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/patches/debian/yama-disable-by-default.patch https://salsa.debian.org/kernel-team/linux/-/blob/master/deb... The decision made there is from 2013 (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712740 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712740), so it might be worth revisiting. Could you file a bug report to get the discussion started?
fluoridation 3y ago
Ha. I did the exact same thing on Windows to inject DLLs into Chrome once. EDIT: Geez. I sure wish I knew what's so objectionable about what I said.
- ImPostingOnHN 3y ago
  I didn't vote either way until you edited your post to add the meta comment. I don't like posters discussing moderation of their posts (I find that discussion about themselves to be vain and distracting from the topic), and I feel gross and off topic myself talking about it even now. The chrome thing sounds cool.
  - throwaway892238 3y ago
    The strange taboos of ingroups
    - deleted 3y ago
      [deleted]
    - ImPostingOnHN 3y ago
      To be fair, the guidelines[0] request of us: > Please don't comment about the voting on comments. It never does any good, and it makes boring reading. Which, yeah. [0] – https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
      - WhackyIdeas 3y ago
        Maybe one day HN will realise that giving the ability to downvote is pretty pointless and needlessly open to abuse. That negative ability just promotes negativity itself and a bloody pia when I am reading a greyed out message because I am too stubborn to go into the settings and change defaults - so I just steam on thinking HN are using a relic of an ideology.
        3y ago
joe_v 3y ago
Hah! I was just referencing this paper the other day when mucking with the linker for an unrelated reason. I probably should have chosen a better name for my article - I am trying to cover the cases of "you have Linux command execution, how do you run native code?" as opposed to your approach which as I understand is more: "you are running native code, how can you load a separate ELF in-process?" Agreed about institutional memory; zines/blogs are very important; but at the end of the day I usually end up just asking in some corner of IRC.
- codethief 3y ago
  > "you have Linux command execution, how do you run native code?" I was going to ask you what the precise situation is in which you'd apply the ideas from the blog post as I don't know what exactly is meant by "process injection". I think the article would benefit from providing a little bit more background for us non-hackers / non-pentesters. Still, very interesting article – thank you! PS: The article says > you need a writable location on disk; this is not always true in e.g. read-only chroots, filesystems, containers, etc Couldn't you create a temporary file in-memory (e.g. in /dev/shm or in some tmpfs), make it executable (+x) and then execute it?
  - joe_v 3y ago
    Apologies it's a little scattered. Roughly it's about dealing with situations where you can execute a command but now want to run a native executable, and how much noise such a thing will make in the presence of monitoring. > Couldn't you create a temporary file in-memory (e.g. in /dev/shm or in some tmpfs), make it executable (+x) and then execute it? It all depends on how your environment is set up: whether a tmpfs or shm device is mounted and writable by your user is up to the admin. For example, on many embedded devices you often want to avoid writes to prevent any sort of filesystem wear, or because you have a write-once media like a ROM; so the whole fs will be mounted readonly. With chroots it's best practice to provide a minimal environment - unless tempfiles are needed there will usually not be a /tmp. Try `docker run --read-only -ti ubuntu bash` as another example: ``` root@9302f159e0e0:/tmp# touch a touch: cannot touch 'a': Read-only file system ```
aengelke 3y ago
Userland exec was a very interesting read when I came across it some years ago; thanks for publishing it! The technique still mostly works, but on recent glibc+Linux, you also have to unregister the rseq area before cleaning out the address space (which requires computing the address first, which is a little cumbersome). Otherwise, if the rseq area is registered but unmapped, the kernel will forcefully stop the program. (That said, nowadays memfd_create + fexecve is likely a more robust alternative in many cases.)
- grugq 3y ago
  Yup, probably the more robust approach.
throwaway892238 3y ago
> we haven’t created an institutional memory beyond “the oldest hacker you know.” Which I'd wager is due to over-reliance on search engines. The net is stuffed to the brim with useless bullshit designed to steal eyeballs, so finding anything somebody published two decades ago is now impossible. Internet Archive is useful if you already know what website used to exist, not so useful if you don't. Whatever happened to that website that was a combination of blog + archive of exploit POCs? Wasn't it called PacketStorm? I just tried to find it with two search engines and came up empty. That would've been an ideal place to track down old techniques and news.
contingencies 3y ago
Happy opseccy new year Grug :)
- grugq 3y ago
  Merry OPSEC, and a happy OPSEC Year!

Retr0id 3y ago

Hi, I'm the author of the `dlinject` tool referenced in the article. Sadly I haven't been maintaining it and it doesn't work on modern distros anymore - not for any fundamental reasons, it just needs some compatibility tweaks. However, it's been forked as `asminject`[1], with bug fixes and other bells and whistles. I consider it to be the latest evolution of that particular approach, and I should probably update the dlinject readme to point at it. Thank you for the writeup! [1] https://github.com/BishopFox/asminject https://github.com/BishopFox/asminject

charcircuit 3y ago

Why does Bash have permission to ptrace or read other process's memory. This should already be locked down, but I suspect it's not because for some reason a lot of systems do not use LSMs or don't care about security in general.

khuey 3y ago
The same bash instance is the parent of the process being attacked so it meets the requirements to ptrace at yama/ptrace_scope == 1.
- Retr0id 3y ago
  In the case of stelf-loader, the bash instance is attacking itself. It's not especially unexpected for a process to be able to modify its own memory.
  - charcircuit 3y ago
    >It's not especially unexpected for a process to be able to modify its own memory. It is unexpected for Bash to do that so it shouldn't be given access to ptrace.
    - Retr0id 3y ago
      stelf-loader does not use ptrace
      - charcircuit 3y ago
        Writing to /proc/pid/mem requires access to ptrace. I never said it would use ptrace directly.
        Retr0id 3y ago
        It's gated by the same access control logic that governs ptrace yes, but it does not use ptrace directly nor indirectly. The first step of that logic is: > If the calling thread and the target thread are in the same thread group, access is always allowed.

gavinray 3y ago

It's a bit wild, but you can use memfd_create to do things like load libraries or binaries, on a filesystem that has no read/write access and noexec enabled. I have been meaning to do a blog post about this, since it doesn't seem to be common knowledge. Originally, I thought of it as a response to a Reddit question: "How can I load a shared library from a .jar directly into memory?" https://old.reddit.com/r/java/comments/15lcwil/load_shared_lib_from_jar_directly_into_memory/jvbyu4i/ https://old.reddit.com/r/java/comments/15lcwil/load_shared_l...

Retr0id 3y ago
> on a filesystem that has... memfd_create's whole selling point is that it isn't backed by a filesystem; it isn't "on" one in the first place, so there is nowhere for it to inherit such restrictions from. The consequences of that can be surprising though, I agree, and are worth exploring and writing about.