3 ms·

You mean _start()'s stack pointer. Libc can secure them and it's fine. It would probably break the ANSI C standard though if you can't modify argv and environ t

by jart 4y ago

You mean _start()'s stack pointer. Libc can secure them and it's fine. It would probably break the ANSI C standard though if you can't modify argv and environ though. So Libc would need to copy them. But that limits the usefulness of the original tooling proposal unless the operating system has something like /proc/pid/maps that tells you the extent of the system provided stack. I don't think OpenBSD has that. Please prove me wrong since if it does, I'd love to know how.

eqvinox 4y ago
> You mean _start()'s stack pointer. Right, yeah. > It would probably break the ANSI C standard though if you can't modify argv and environ though. AFAIK it would also break setproctitle(), unless my memory is off that works by just writing over the argv space. On the plus side, on Linux /proc/<pid>/environ is a snapshot created at the time of execve() and kept by the kernel, nothing other than execve() can change it (don't quote me on this, I'm only 90% sure.)
- 7vUYjPAG2fnx7fd 4y ago
  No setproctitle on Linux. As far as I know you have to overwrite the argv space (and hopefully not also the environment space).
  - eqvinox 4y ago
    Looking at the sibling post to yours, I'm assuming the "better" approach these days is to allocate a new buffer distinct from argv space and use PR_SET_MM_ARG_{START,END} to point the kernel there.
- jcranmer 4y ago
  > On the plus side, on Linux /proc/<pid>/environ is a snapshot created at the time of execve() and kept by the kernel, nothing other than execve() can change it (don't quote me on this, I'm only 90% sure.) prctl(PR_SET_MM_ENV_{START,END}) will change the contents of /proc/<pid>/environ. From what it looks like in Linux's source code, twiddling the bits at the base of the stack will also cause the procfs file to change--it seems to read directly from the process's memory. Ditto for /cmdline and /auxv, it seems.
  - eqvinox 4y ago
    Now I'm sad :( … but Thanks for removing a misconception of mine!
    - staticassertion 4y ago
      Yep, dug into this the other day and POC'd it to prove that (even without prctl, just direct writing) you can overwrite those values and that will be shown in proc.

by jart 4y ago

eqvinox 4y ago

> You mean _start()'s stack pointer. Right, yeah. > It would probably break the ANSI C standard though if you can't modify argv and environ though. AFAIK it would also break setproctitle(), unless my memory is off that works by just writing over the argv space. On the plus side, on Linux /proc/<pid>/environ is a snapshot created at the time of execve() and kept by the kernel, nothing other than execve() can change it (don't quote me on this, I'm only 90% sure.)

7vUYjPAG2fnx7fd 4y ago
No setproctitle on Linux. As far as I know you have to overwrite the argv space (and hopefully not also the environment space).
- eqvinox 4y ago
  Looking at the sibling post to yours, I'm assuming the "better" approach these days is to allocate a new buffer distinct from argv space and use PR_SET_MM_ARG_{START,END} to point the kernel there.
jcranmer 4y ago
> On the plus side, on Linux /proc/<pid>/environ is a snapshot created at the time of execve() and kept by the kernel, nothing other than execve() can change it (don't quote me on this, I'm only 90% sure.) prctl(PR_SET_MM_ENV_{START,END}) will change the contents of /proc/<pid>/environ. From what it looks like in Linux's source code, twiddling the bits at the base of the stack will also cause the procfs file to change--it seems to read directly from the process's memory. Ditto for /cmdline and /auxv, it seems.
- eqvinox 4y ago
  Now I'm sad :( … but Thanks for removing a misconception of mine!
  - staticassertion 4y ago
    Yep, dug into this the other day and POC'd it to prove that (even without prctl, just direct writing) you can overwrite those values and that will be shown in proc.