On Tue, Sep 1, 2015 at 9:18 PM, Rich Felker <dalias@xxxxxxxx> wrote:Did the old versions of glibc always use vsyscall calling for these syscalls? If they did, then we could (probably) safely disable the vsyscall stuff the first time we see any of these called through the normal syscall paths.
On Tue, Sep 01, 2015 at 08:39:27PM -0700, Andy Lutomirski wrote:
On Tue, Sep 1, 2015 at 7:54 PM, Rich Felker <dalias@xxxxxxxx> wrote:
If this is not the case, I have what sounds like an elegant solution,
if it works: presumably affected versions of glibc that used this used
it for all syscalls, so if the process has made any normal syscalls
before using the vsyscall addresses, you can assume it's a bug/attack
and and just raise SIGSEGV. If there are corner cases this doesn't
cover, maybe the approach can still be adapted to work; it's cleaner
than introducing header cruft, IMO.
Unfortunately, I don't think this will work. It's never been possible
to use the vsyscalls for anything other than gettimeofday, time, or
getcpu, so I doubt we can detect affected glibc versions that way.
I thought the idea of the old vsyscall was that you always call it
rather than using a syscall instruction and it decides whether it can
do it in userspace or needs to make a real syscall. But if it was only
called from certain places, then yes, I think you're right that my
approach doesn't work.
No, it's actually just three separate functions, one for each of
gettimeofday, time, and getcpu.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature