On Fri, 16 Nov 2012 15:46:00 -0500 (EST) Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote: > Nobody has quite come right out and said what the race supposedly > remaining with fexecve is, or at least not that I've seen; the only > one I've been able to think of is a TOCTOU race with someone > overwriting the file between check and execute, and that one fexecve > does not solve. Yes, sorry, should have been explicit. That's the ridiculously obvious one. > (It could be tweaked to solve it, by (for example) making O_EXEC (a) > required for fexecve and (b) lock the file against writes in the same > way executing it does, the way that's behind ETXTBSY.) Which would be contrary to the spec anyway, no? If an implementation needs to be non-compliant to be safe, is that better or worse than just not having it at all? O_EXEC seems to exist on FreeBSD but not on OpenBSD or Linux so I doubt there's much code out there that would work unmodified with such an implementation. > It's true fexecve doesn't solve the latter, but the bar _is_ higher; > assuming checking involves checking ownership as well as contents, > exploiting it requires the ability to overwrite a file owned by > whatever user the check is checking for. To make this statement, presumably you're also tacitly assuming checking permissions? Doesn't matter who owns it if it's world writeable. > (If, as is probably the case in many such uses, that user is root, I > have trouble seeing _any_ issue here - anyone who can overwrite > root-owned files pretty much pwnz0rz the system already.) Depends whether they can overwrite all root-owned files, or just specific ones (due to some other exploit). Julian -- 3072D/F3A66B3A Julian Yon (2012 General Use) <pgp.2012%jry.me@localhost>
Attachment:
signature.asc
Description: PGP signature