3 ms·

You should file a CVE for this exploit for the government agencies that still use the PDP-11, probably like the US nuclear arsenal command. Joke's aside, I tho

You should file a CVE for this exploit for the government agencies that still use the PDP-11, probably like the US nuclear arsenal command. Joke's aside, I though this was an easy and fun read.

varjag 3y ago
Missile command's PDPs are securely air-gapped via RX02 8" floppy drives.
basementcat 3y ago
This is not a vulnerability in 2BSD but rather a consequence of the CPU not having the capability to mark the relevant area of memory as non executable. EDIT: Actually a fix may not be impossible as 2BSD makes use of the PDP11's ability to have a 64kB text bank and a distinct 64kB data bank. I suspect this may require a major redesign.
- dfox 3y ago
  It is trivial and intentional bug in the presented hackme.c. The strcpy() to stack allocated buffer there serves no useful purpose (one can just call the printf() with argv[1] directly), but is an obvious thing to exploit. Also, W^X would not really help there, as what gets overwritten is return address on stack, which is simply data and does not get executed. You would need some kind of stack canaries or control-flow integrity to catch that, which is probably somewhat complicated by the fact that it is in main(). (And also, on PDP-11 overhead of such schemes will probably be significant)
- fsckboy 3y ago
  >This is not a vulnerability in 2BSD but rather a consequence of the CPU not having the capability to mark the relevant area of memory as non executable. well, it was a consequence of vulnerabilities like this that CPUs added the capability to mark areas of memory as non-executable, more or less an extension of protected modes that separated different users. The original von neumann idea that you could execute wherever the program counter was pointing was absolutely "feature" if not "obviously". The harvard architecture separating code and data space was "twice the address space in the same number of bits" beyond its "well the buses are separate anyhow"
- Taniwha 3y ago
  No, this is a C runtime bug in the program (nothing to do with pdp11s or BSD), they're overwriting the return address on the stack
  - hulitu 3y ago
    This can be solved by porting rust to pdp-11. /s
    - ithkuil 3y ago
      llvm backend for pdp-11: lldpd

You should file a CVE for this exploit for the government agencies that still use the PDP-11, probably like the US nuclear arsenal command. Joke's aside, I though this was an easy and fun read.

varjag 3y ago

Missile command's PDPs are securely air-gapped via RX02 8" floppy drives.

basementcat 3y ago

This is not a vulnerability in 2BSD but rather a consequence of the CPU not having the capability to mark the relevant area of memory as non executable. EDIT: Actually a fix may not be impossible as 2BSD makes use of the PDP11's ability to have a 64kB text bank and a distinct 64kB data bank. I suspect this may require a major redesign.

dfox 3y ago
It is trivial and intentional bug in the presented hackme.c. The strcpy() to stack allocated buffer there serves no useful purpose (one can just call the printf() with argv[1] directly), but is an obvious thing to exploit. Also, W^X would not really help there, as what gets overwritten is return address on stack, which is simply data and does not get executed. You would need some kind of stack canaries or control-flow integrity to catch that, which is probably somewhat complicated by the fact that it is in main(). (And also, on PDP-11 overhead of such schemes will probably be significant)
fsckboy 3y ago
>This is not a vulnerability in 2BSD but rather a consequence of the CPU not having the capability to mark the relevant area of memory as non executable. well, it was a consequence of vulnerabilities like this that CPUs added the capability to mark areas of memory as non-executable, more or less an extension of protected modes that separated different users. The original von neumann idea that you could execute wherever the program counter was pointing was absolutely "feature" if not "obviously". The harvard architecture separating code and data space was "twice the address space in the same number of bits" beyond its "well the buses are separate anyhow"
Taniwha 3y ago
No, this is a C runtime bug in the program (nothing to do with pdp11s or BSD), they're overwriting the return address on the stack
- hulitu 3y ago
  This can be solved by porting rust to pdp-11. /s
  - ithkuil 3y ago
    llvm backend for pdp-11: lldpd