• Eric W. Biederman's avatar
    signal: Extend exec_id to 64bits · 8323587c
    Eric W. Biederman authored
    BugLink: https://bugs.launchpad.net/bugs/1875905
    
    commit d1e7fd64 upstream.
    
    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.
    
    Link: https://lore.kernel.org/kernel-hardening/20200324215049.GA3710@pi3.com.pl
    Fixes: 2.3.23pre2
    Cc: stable@vger.kernel.org
    Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: default avatarIan May <ian.may@canonical.com>
    Signed-off-by: default avatarKleber Sacilotto de Souza <kleber.souza@canonical.com>
    8323587c
exec.c 42.6 KB