History

signal: Extend exec_id to 64bits

Replace the 32bit exec_id with a 64bit exec_id to make it impossible to wrap the exec_id counter. With care an attacker can cause exec_id wrap and send arbitrary signals to a newly exec'd parent. This bypasses the signal sending checks if the parent changes their credentials during exec. The severity of this problem can been seen that in my limited testing of a 32bit exec_id it can take as little as 19s to exec 65536 times. Which means that it can take as little as 14 days to wrap a 32bit exec_id. Adam Zabrocki has succeeded wrapping the self_exe_id in 7 days. Even my slower timing is in the uptime of a typical server. Which means self_exec_id is simply a speed bump today, and if exec gets noticably faster self_exec_id won't even be a speed bump. Extending self_exec_id to 64bits introduces a problem on 32bit architectures where reading self_exec_id is no longer atomic and can take two read instructions. Which means that is is possible to hit a window where the read value of exec_id does not match the written value. So with very lucky timing after this change this still remains expoiltable. I have updated the update of exec_id on exec to use WRITE_ONCE and the read of exec_id in do_notify_parent to use READ_ONCE to make it clear that there is no locking between these two locations.

Eric W. Biederman committed 6 years ago

Commit d1e7fd61 parent 4b871ce3 files · +4 −4Browse files

Showing the changes to include/linux (1 of 3 files). Show all

Unified · Split

include/linux/sched.h+2−2
@@ -939,8 +939,8 @@ struct task_struct { · 938 unmodified lines
939 struct seccomp seccomp;939 struct seccomp seccomp;
940 940
941 /* Thread group tracking: */941 /* Thread group tracking: */
942 u32 parent_exec_id;942 u64 parent_exec_id;
943 u32 self_exec_id;943 u64 self_exec_id;
944 944
945 /* Protection against (de-)allocation: mm, files, fs, tty, keyrings, mems_allowed, mempolicy: */945 /* Protection against (de-)allocation: mm, files, fs, tty, keyrings, mems_allowed, mempolicy: */
946 spinlock_t alloc_lock;946 spinlock_t alloc_lock;