[grugq]

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

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.”

[throwaway892238]

> 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.

[Retr0id]

> 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.

[secure]

The Debian patch for this setting is: 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), so it might be worth revisiting.

Could you file a bug report to get the discussion started?

[deadlydose]

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]

You can configure it on most distros, it doesn't excuse having an insecure default.

[joe_v]

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]

> "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]

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 ```

[codethief]

My apologies for the delay, Joe, I was on vacation. Now that I'm home, I gave this a try but at least on my machine writing to /dev/shm/ works as I remembered, even with --read-only:

    $ docker run --read-only -ti ubuntu bash
    root@3dfdab770505:/# echo "bar" > /dev/shm/foo
    root@3dfdab770505:/# cat /dev/shm/foo
    bar

So, again, couldn't you just write your binary to /dev/shm and execute it?

[infotogivenm]

It is fairly common to have noexec on /dev/shm; filesystem configurations are always up to the admin so they could feasibly set anything.

[codethief]

Thanks for reminding me of noexec; I'm no Linux security expert by any means, so I was merely trying to figure out what's possible and what's not.

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.

[grugq]

Ah, so, in 2005 I wrote about that when I implemented rexec() — remote exec() — which takes a binary and then copies it over an arbitrary text only link (like ssh) and executes it completely in memory without touching disk.

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.

[joe_v]

That is a really useful implementation and a good way to use gdb to "live off the land". It is interesting how ops changes like moving to containers/VMs affect pentesting techniques; over the last decade I find myself relying less and less on live-off-the-land in a lot of engagements. When you can use them though they have a lot of advantages.

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.

[grugq]

Syscall proxying was very old even when I wrote that article. The problem with syscall proxying is that it is slow. Take any process and imagine adding network latency to every single syscall. On a local network is incredibly slow, but over any sort of real distance it is just impossible.

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.

[joe_v]

That makes sense, something like `grep $USER /etc/passwd` would shuffle the whole passwd file over the wire, etc; for a lot of post-exploitation stuff I could see it causing more trouble than it's worth.

[grugq]

Oh, it’s far far worse than that. Just the core operation would be:

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.

[aengelke]

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]

Yup, probably the more robust approach.

[fluoridation]

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.

[Retr0id]

I didn't vote, but to answer your question, you couldn't possibly have done the "exact same thing" as a linux-specific userland exec technique and have it work as a DLL injection technique on Windows. I'm sure it could've been conceptually similar, but not identical, and maybe those differences would be interesting to discuss.

[fluoridation]

"Exact same thing" as in re-implemented a basic OS feature in user mode to bypass an intercepted feature. Obviously it can't be literally exactly the same thing, because that wouldn't be implementing something, but rather using existing source code.

[ImPostingOnHN]

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.

[fluoridation]

I didn't comment about the voting itself, I asked what was wrong with my comment. There's a difference between "oh, I'm getting down-voted, this sucks" and "what's wrong with what I said?" The former is whining, while the latter invites discussion. If telling someone else what you think about their comment counts as "meta" discussion and is therefore boring then that kind of kills the purpose of a discussion forum.

[throwaway892238]

The strange taboos of ingroups

[ImPostingOnHN]

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

[WhackyIdeas]

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.

[throwaway892238]

It's an ingroup reinforcement method.

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.

[contingencies]

Happy opseccy new year Grug :)

[grugq]

Merry OPSEC, and a happy OPSEC Year!