Unprivileged process injection techniques in Linux
joev.dev
joev.dev
Thank you for the writeup!
Exactly 20 years ago I wrote and released userland exec().
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.”
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.
The decision made there is from 2013 (see 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?
EDIT: Geez. I sure wish I knew what's so objectionable about what I said.
The chrome thing sounds cool.
> Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
Which, yeah.
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.
If you're part of a cult, and you're not allowed to eject someone from the cult, you can at least ignore them or walk away from them when they talk to you, if you don't agree with what they say/do. It's a way for the members of the cult to reinforce the ingroup's behaviors without having overt power over the group. For other people watching this behavior, it reinforces the need to align themselves with the larger group, to avoid the same fate.
The first rule of fight club is you don't talk about fight club.
I'm not sure where some folks got the idea that they could say whatever they wanted in whatever community they wanted and not expect any reactions, but that's clearly an inhuman expectation. I'm guessing that attitude is a byproduct of internet commenting.
I guess you could call society an "ingroup" or a "cult" like you're doing. It technically fits the definition. It also gives you a convenient victim complex to wave about whenever you feel like people aren't agreeing with you enough. But let's be honest: not every social pariah is a Galileo.
As to your assertion ("idea that they could say whatever they wanted in whatever community they wanted and not expect any reactions"), I don't think I or anyone else said that or suggested it. Sounds like a sweeping generalization designed to reinforce an opinion you want to believe. But it also seems like you drank the kool-aid a while back, so I'm pretty sure I can't influence your opinion.
Either way, the label is being self-applied here to indulge a victim complex in someone who doesn't like that society is reacting to their decision to go against society. Consider that total jerks and crazy folks use exactly the same logic.
Not that anyone here is a jerk, or crazy, just that the "I'm an independent thinker and everyone else is drinking the kool aid" argument is tired and oblivious and self-indulgent and applies equally when used by jerks and nuts. The dude on the street corner shouting racial slurs at the top of their lungs and swatting at invisible spiders thinks he's "just part of the out group", too.
Usually, historically, if you said something someone didn't like you could expect the person to either confront you directly, or to silently change their opinion of you and possibly change their behavior, perhaps to your detriment. Even before the Internet existed, there was something else someone might have done, which is to send you an anonymous note reading "fuck you". No argument, no way to reply, nothing but a cheap gratuitous offense that serves no purpose other than upset the person who receives it. I argue that downvoting a comment you don't like is equivalent to that.
A better equivalent would be arguing from an anonymous throwaway account (*cough*), where any replies go into the void, rather than to an established community member.
A comment either adds value in people's opinion, or it detracts, or neither. The society that is HN has a voting system to communicate that info, because that is what we prefer.
If people find the non-meta substance of a post interesting enough to reply, they absolutely will do so. But we have the guidelines recommending against moderation meta-discussion because you and the moderation of your comment aren't the topic, and you shouldn't try to make it the topic, because we find that to be more boring than the actual topic. Maybe you find yourself more interesting, or you think conversation is boring unless it includes moderation meta-discussion. In most cases, I don't think others agree (hence the guidelines and the voting).
You can call our society an "in-group", you can call someone who ignores what society wants an "out group member", but in the end, I don't know why it surprises people that society responds with feedback (though perhaps not in the exact feedback format one may personally prefer).
I don't agree with this. How can you say that your reply "goes into the void", just because the name of the account you're responding to is "throwaway892238" rather than "fluoridation"? In either case there's a person on the other end, how does the screen name they go by change anything? I could equally say that unless you tell me your real name, or unless you let me put my hand down your pants, or any other equally arbitrary standard, I don't consider you a real person. Neither the screen name, nor their real name, nor what's in their pants, is what the actual person is.
I have no idea which of our community members any given throwaway is, I'll never know, their comments are just anonymous notes left with no way to respond to an actual member of our community with an actual history and an actual reputation (vs a throwaway they may never check again). That's why a throwaway comment is like an anonymous "fuck you" note. Or, put another way:
> Throwaway accounts are ok for sensitive information, but please don't create accounts routinely. HN is a community—users should have an identity that others can relate to.[0]
My point is further supported by the rest of my post that you responded to, which is the substance of our discussion. Continuing to argue over an analogy instead of the substance of the matter would be silly.
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.
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?
> 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 ```
$ docker run --read-only -ti ubuntu bash
root@3dfdab770505:/# echo "bar" > /dev/shm/foo
root@3dfdab770505:/# cat /dev/shm/foo
bar
It looks like mounting /dev/shm with noexec is not that common, though, is it? See e.g.
https://unix.stackexchange.com/questions/670362/mounting-dev...
More generally, it regularly blows my mind how hard it is to harden a Linux installation, and how many pitfalls and caveats there are.
http://phrack.org/issues/62/8.html
The idea was that if you have access to a box via a shell and you want to run your own binary without leaving evidence behind, you’d use rexec() to do that.
Also never realized that others have implemented (and I guess patented?) syscall proxying, I have heard that idea discussed before for offensive tooling and wondered how well it works in practice.
That’s why I pushed everything to the target system. Run it local as much as possible.
Back then there were no containers or VMs to use. These days I think you should be bringing your environment with you. Unless there are serious reasons not to.
open() — network round trip fstat() — network round trip brk() — network round trip read() — network round trip Shuffle data over network read() — network round trip Shuffle data over network
Etc etc
For a “grep root /etc/passwd” there are 88 syscalls on a Debian 11. If we assume a very generous 50ms latency for every syscall, that means we’re waiting 4.4s for the result.
The use case for syscall proxying is limited to when you don’t want to upload an exploit onto a target machine, but you need to run the exploit on that machine. So it could be an LPE or something.
It is way too slow for post exploitation work.
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.)
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.
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_l...
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.
It is unexpected for Bash to do that so it shouldn't be given access to ptrace.
> If the calling thread and the target thread are in the same thread group, access is always allowed.