Quarantine.kext; hook_vnode_check_exec()

Questions and Answers about all things *OS (macOS, iOS, tvOS, watchOS)

Quarantine.kext; hook_vnode_check_exec()

Postby patrick » Sun Sep 13, 2015 6:15 am

I know this will be covered in detailed in the second version of your book (can't wait!), but I was wondering if you could briefly explain what Quarantine.kext does; specifically the MAC-related hook_vnode_check_exec function? I (think) I understand how quarantine files work in user-mode (extended attributes, LaunchServices framework talking to CoreServicesUIAgent to prompt the user to confirm, etc, etc).

I also see that the hook_vnode_check_exec function returns early, if _sandbox_enforce is FALSE, _require_user_approved_exec is FALSE, or if the binary's quarantine flags (com.apple.quarantine) contain 0x40 (i.e previously run & approved). However if it is the first time a downloaded (quarantined) file is run - the code will continue executing. I see a bunch of locking, it accessing _label_slot, checking/decrementing some vars- before returning with 0 (ok?). Though I see some code that has some interesting strings such as "exec of %s denied since it was quarantined by %s and %s, qtn-flag" this does not appear to be executed. So I guess my question is, what does hook_vnode_check_exec() do when it encounters a quarantine file about to be executed for the first time? And how does this influence the rest of the (user-mode) validation/alerting the user process?

thanks!
patrick
 
Posts: 7
Joined: Mon May 04, 2015 5:04 am

Re: Quarantine.kext; hook_vnode_check_exec()

Postby morpheus » Mon Nov 16, 2015 3:53 am

Ack. Sorry I totally missed that one, Patrick. My bad.

The short version of the answer is, that quarantine.kext is horribly broken. In 10.10(.3, which is the version I use for research), you can easily bypass it, as it only actually works to augment Finder based launches of programs. Even if "your policy disallows blah blah blah", you can just open up a terminal and run it from a prompt, and it will work. A good example is my own procexp tool, which I do not signed, and still runs (you can get the raw binary , not the tgz, to try, at http://NewOSXBook.com/files/procexp). It automatically gets quarantined:

Code: Select all
bash-3.2# ls -l@ ~/Downloads/procexp
-rwxr-xr-x@ 1 morpheus  staff  495180 Nov 15  2015 /Users/morpheus/Downloads/procexp
   com.apple.metadata:kMDItemDownloadedDate       53
   com.apple.metadata:kMDItemWhereFroms       82
   com.apple.quarantine       57
bash-3.2# ~/Documents/OSXBook/Book/xattr ~/Downloads/procexp  1
Attribute: com.apple.metadata:kMDItemDownloadedDate
Value:
62 70 6c 69 73 74 30 30 a1 01 33 41 bb f9 83 24  b p l i s t 0 0 ?  3 A ? ? ?
fb d3 b3 08 0a 00 00 00 00 00 00 01 01 00 00 00 $ ? ? ?
           
00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00                 
00 00 00 00 13
Cprotect: -1
Attribute: com.apple.metadata:kMDItemWhereFroms
Value:
62 70 6c 69 73 74 30 30 a1 01 5f 10 23 68 74 74  b p l i s t 0 0 ?  _  # h t
70 3a 2f 2f 6e 65 77 6f 73 78 62 6f 6f 6b 2e 63 t p : / / n e w o s x b o o k .
6f 6d 2f 66 69 6c 65 73 2f 70 72 6f 63 65 78 70 c o m / f i l e s / p r o c e x
08 0a 00 00 00 00 00 00 01 01 00 00 00 00 00 00 p
             
00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00                 
00 30
Cprotect: -1
Attribute: com.apple.quarantine
Value:
30 30 30 32 3b 35 36 34 39 34 62 61 34 3b 53 61  0 0 0 2 ; 5 6 4 9 4 b a 4 ; S
66 61 72 69 3b 41 43 31 42 39 44 45 46 2d 43 37 a f a r i ; A C 1 B 9 D E F - C
34 36 2d 34 39 34 34 2d 42 30 35 45 2d 32 42 30 7 4 6 - 4 9 4 4 - B 0 5 E - 2 B
30 45 39 37 37 30 33 39 41
Cprotect: -1



I actually just tested this on 10.11.1, and guess what - with SIP enabled - still just as broken, despite the restriction for code signing by trusted dev or App store apps only. Quarantine doesn't actually enforce anything. See that in the screenshot (in the back terminal, you can see Procexp having run because it complains about CTRL-C). So you see, Finder looks at the extended attributes, and decides accordingly - before doing the exec. You are correct that the vnode_exec hook short circuits (returns 0, which is a-o-k-ask-somebody-else). I can only guess that Apple has decided for whatever reason to allow quarantine to let the kext rest in kernel mode, but not really enforce it. It does seem to enforce the setxattr, though.

Now, is this a 0 day ? More like (yet another) 1000+ day. It's kind of known. As far as I can recall, you addressed that in your presentation as well. There are far, far worse 0-days. But that's not my business to disclose. People still haven't figured out one that is still alluded to in MOXiI 1st ed (though Apple apparently eventually did). MOXiI 2nd ed will likely show a couple more :-) If you investigate this further and raise this with Apple, tell them I said hello :-)
Attachments
Screen Shot 2015-11-15 at 22.35.54.png
Screen Shot 2015-11-15 at 22.35.54.png (567.46 KiB) Viewed 3107 times
morpheus
Site Admin
 
Posts: 530
Joined: Thu Apr 11, 2013 6:24 pm

Re: Quarantine.kext; hook_vnode_check_exec()

Postby patrick » Tue Nov 24, 2015 11:35 pm

Thanks for your detailed explanation :) So my follow up question is - what does Quarantine.kext actually do when a app is launched via Finder (specifically via launch services framework). Specifically, I see that when I double-click on a file the hook_vnode_check_exec function gets called. In the disassembly I see that it (on OS X 10.10.*) appears to check (and exit early with OK), if the executable is on a read-only file-stystem (e.g. read-only DMG?), etc.

call _vfs_flags ; mnt flags
test al, MNT_RDONLY
jnz leaveFunction

or equally bails with OK if the file was previously approved by the user.

call _quarantine_get_flags
and eax, 40h ;0x40 when user previously allowed
jnz leaveFunction

So when would Quarantine.kext and hook_vnode_check_exec() actually block a file?
thanks!

-patrick
patrick
 
Posts: 7
Joined: Mon May 04, 2015 5:04 am


Return to Questions and Answers

Who is online

Users browsing this forum: No registered users and 4 guests