Weird Disk Utility msg in Snow Leopard

[Hal Itosis]

Quote: Originally Posted by Red_Menace Although i didn't mean "not to worry", Apple has posted a support document - is there something else that people would take as seriously?

No, what you did there was fine... inasmuch as that setuid binary named "Locum" (with parent pathname /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/Resources/) does indeed appear on the list in article TS1448).

I just feel that any reassuring references to article TS1448 should be accompanied with some words to the effect that behind all this is some tiny design flaw which needs to be addressed.

It's just unfortunate we users are put in this position in the first place. But, we should not succumb to this situation or send signals to others that this current status quo in "DURP" is to be regarded as acceptable behavior.

What good is all this fancy technology unless engineers and technicians take care to assemble it correctly? [e.g., it seems sorta pointless when various "code-signed" objects fail validation as shipped.]

Quote: Originally Posted by Red_Menace So what is your recommendation?

Just to be aware. In the real world, a sentence containing both the words "warning" and "suid" is something to which one would normally need pay serious attention.

As far as using some Terminal trick to "tweak" the named files themselves, it's not necessary. In 99.9% of these cases (i.e., false positives), the item itself is already correct... it's just that Disk Utility isn't getting the proper info, which would otherwise confirm that fact. [there might be some fancy "pkgutil --learn" footwork we could resort to, but i haven't gotten that advanced yet... anyway, rightfully that's Apple's job.]

[Hal Itosis]

Quote: Originally Posted by tw this is a systemic phenomenon that affects any active, ongoing, organized structure. think of it as systemic relativity: something occurs at point A and something else occurs at point B, and both effects ripple through the system at a variable but finite rate, and interact at some other place(s) and time(s) to produce the occasional unintended effect. So, apple sets up a receipts system designed to keep track of the numerous changes that happen.Someone working on project A makes a change to permissions on some file or folder; Someone else working on project B makes a different change to the same permissions; Both get recorded properly in the distinct receipts and one of them (by necessity) is going to cause DU to complain. it's particularly problematic when you think about big subgroups (like the iTunes people, or the Web Core people, or the Darwin people) which will have their own internal hierarchies. Or someone makes a change and just plain forgets to add it to the receipt. Or a random computer glitch makes a change in a receipt without anyone realizing. Or a change gets made by a third party provider or an individual user (because they're part of this system as well). to catch any of these cases you'd need some human eye to recognize that see that there's a mismatch, and whoever that is would need to negotiate a fix with the people who caused the mismatch, and that recognition and negotiation process is prone to error on any of a number of levels, and takes time, and so the error (if it occurs) is likely to persist for a bit.

A fanciful tale... and so beautifully told.

But unfortunately, none of that applies to the suid warning in post #1 (or anything else in the TS1448 list). If you took some time to actually *study* the situation (instead of fabricating plausible scenarios to pacify the proles), you'd see that the correct info already exists inside the package receipt itself!!! But for some as yet unknown reason (re: bug), sometimes -- seemingly randomly -- the software update process doesn't transfer that info from the bom inside the package to that "boms" folder in Receipts, and finally into the a.receiptdb file. Is any of this sinking in yet? -- No?

Follow me...

1. here's a typical line from a typical report (generated by DURP after last night's SecUpdt2009-006 was installed):
   2009-11-10 02:37:01 -0500: Permissions differ on "Applications/iTunes.app/Contents/CodeResources", should be -rw-rw-r-- , they are lrw-rw-r-- .
   
   Oh dear, DU was expecting a file. But what's that i see... a symlink? How can this be? Well... let's see.
   
   .
2. i wonder what sorta info about "/Applications/iTunes.app/Contents/CodeResources" might be lounging around /Library/Receipts:
   

   
   $ find /Library/Receipts -name '*.bom' |while read x; do if lsbom -p MUGsf "$x" |
   grep -E '\./Applications/iTunes.app/Contents/CodeResources$'; then echo "$x"; echo; fi; done
   
   -rw-rw-r-- 	root	admin	18849	./Applications/iTunes.app/Contents/CodeResources
   /Library/Receipts/boms/com.apple.pkg.iTunes.bom
   
   lrwxrwxr-x 	root	admin	28	./Applications/iTunes.app/Contents/CodeResources
   /Library/Receipts/iTunesX.pkg/Contents/Archive.bom
   
   lrwxrwxr-x 	root	admin	28	./Applications/iTunes.app/Contents/CodeResources
   /Library/Receipts/iTunesX.pkg/Contents/Resources/iTunesX.bom
   

   .
3. okay, 3 entries show up in what appears to be 3 different boms... but we should verify that:
   

   
   $ ls -ltTr /Library/Receipts/{boms/com.apple.pkg.iTunes.bom,iTunesX.pkg/Contents/{Archive.bom,Resources/iTunesX.bom}}
   -rw-r--r--  1 _installer  wheel  881987 Sep 25 05:17:15 2007 /Library/Receipts/boms/com.apple.pkg.iTunes.bom
   -rwxrwxr-x  1 root        admin  926415 Jul 13 17:40:47 2009 /Library/Receipts/iTunesX.pkg/Contents/Archive.bom
   lrwxr-xr-x  1 halito      wheel      14 Sep  3 10:42:05 2009 /Library/Receipts/iTunesX.pkg/Contents/Resources/iTunesX.bom -> ../Archive.bom
   

   Oh i see, iTunesX.bom is merely a symlink to its package's /Archive.bom so... looks like /Library/Receipts/iTunesX.pkg/Contents/Archive.bom is the latest and the greatest (as far as boms with what we're looking for goes).
   
   .
4. so we better take a second look just to verify the search in step 2 wasn't flawed:
   

   
   $ lsbom -p MUGsf /Library/Receipts/iTunesX.pkg/Contents/Archive.bom |grep Contents/CodeResources
   lrwxrwxr-x 	root	admin	28	./Applications/iTunes.app/Contents/CodeResources
   lrwxrwxr-x 	root	admin	28	./Applications/iTunes.app/Contents/Frameworks/InternetUtilities.bundle/Contents/CodeResources
   lrwxrwxr-x 	root	admin	28	./Applications/iTunes.app/Contents/Resources/iTunesHelper.app/Contents/CodeResources
   

   Sho'nuff... the bom dated Jul 13 17:40:47 2009 (iTunes 8.2.1) is telling us that "lrwxrwxr-x root admin" is the desired flavor of permission/mode/ownership/etc. If we were a Tiger OS repairing permissions, there would be no more questions.
   
   .
5. So what's the "problem" then? Why does DURP in step 1 claim that "should be -rw-rw-r--" is supposedly correct? Is this one of those "negotiation mismatches" you were fantasizing about? No, wait... how could it be? The correct info is sitting right here on my HD in /Library/Receipts/iTunesX.pkg/Contents/Archive.bom dated Jul 13 2009.
   
   Whither comes "should be -rw-rw-r--" from? You don't suppose DURP would be silly enough to be reading that old /Library/Receipts/boms/com.apple.pkg.iTunes.bom from Sep 25 05:17:15 2007 -- do you? And what does it contain?
   

   
   $ lsbom -p MUGsf /Library/Receipts/boms/com.apple.pkg.iTunes.bom |grep /Applications/iTunes.app/Contents/CodeResources
   -rw-rw-r-- 	root	admin	18849	./Applications/iTunes.app/Contents/CodeResources
   

   So... is that the problem then?
   
   .
6. Sort of, but not quite. Leopard's DURP doesn't read either of those boms directly. Remember a.receiptdb? Isn't that where DURP looks? Isn't that where we should also look?
   

   $ pkgutil -v --file-info /Applications/iTunes.app/Contents/CodeResources
        volume: /
          path: Applications/iTunes.app/Contents/CodeResources
   
          pkgid: com.apple.pkg.iTunes
    pkg-version: 7.4.2.1.1192168948
   install-time: Thu Nov 29 14:17:16 2007
            uid: 0 (root)
            gid: 80 (admin)
           mode: 100664 (-rw-rw-r-- )

   Q.E.D.

The latest info was never transferred into the database, even though it's been sitting on my HD since i installed iTunes 8.2.1 sometime in September. (And perhaps several other earlier installs as well). So there must be some flaw in the software update process [a sloppy post-install script perhaps?]. And that's the reality... not some daydream.

So now... with your permission, i'll repair to the dining room.

[note: i used a 'CodeResources' example here because all my suid items are fine (plus CodeResources represent the most prevalent offenders). If someone has some other *specific* file they want traced (or a false belief they need fixed), just post it so we can walk (or talk) it through.]

[Hal Itosis]

Quote: Originally Posted by tw however - if most of the messages are false alarms, then the advice to ignore them is generally accurate and appropriate, and the problem then becomes one of identifying the few real issues that are best looked into. It'd be kind of nice to have a list of SUID warnings that shouldn't be ignored...

The hacker in me is ROTFLOL. Another way to view article TS1448 is:
"H3y h4c|<0/2z... h3/23 i5 4 1i57 0f 537uid phi135 7h47 /V\4c ph4nb0y5 vvi11 n3v3/2 d0ub13-ch3c|<"
[hey hackers, here is a list of setuid files that Mac fanboys will never double-check]

Quote: Originally Posted by tw It's a bit off-base to assert that DU needs to be 'fixed' because it has a 'bug' because it's not very good at a task it was never designed to do.

And wasn't its initial lack of 'design' the very reason that DU was totally revamped in Leopard? Have we conveniently forgotten MoAB already? Why do you suppose the message in post #1 appears in the first place? Did we ever see such a thing in Tiger or Panther (or earlier)?

Perhaps a little historical perspective would help the readers. I.e., do that googly thing on:

• MOAB-05-01-2007
• MOAB-15-01-2007

The whole reason that DU now even bothers to examine suid files so closely is precisely because its previous versions were vulnerable in the sense that hackers could employ DU [or diskutil without any human involvement!] as their trusted assistant. One reason a permissions repair run takes so long in Leopard (compared to Tiger, etc) is that the SHA-1 digest of every single *Mac OSX* suid file (past and present) is being tracked.

For example... the file in post #1:

$ pkgutil -v --file-info /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/Resources/Locum
     volume: /
       path: System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/Resources/Locum

       pkgid: com.apple.pkg.BaseSystem
 pkg-version: 10.5.0.1.1.1192168948
install-time: Thu Nov 29 14:04:37 2007
         uid: 0 (root)
         gid: 0 (wheel)
        mode: 104755 (-rwsr-xr-x )
        sha1: <5c083e59 550156ce 9c29dccd 2c1b03ee ee8de0f7>

       pkgid: com.apple.pkg.update.os.10.5.1
 pkg-version: 1.0.1.1191932192
install-time: Thu Nov 29 17:08:57 2007
         uid: 0 (root)
         gid: 0 (wheel)
        mode: 104755 (-rwsr-xr-x )
        sha1: <000b4eee d7abf1d1 9d7502c9 61aca444 b706dea5>

       pkgid: com.apple.pkg.update.os.10.5.2.combo
 pkg-version: 1.0.1.1191932192
install-time: Mon Feb 11 23:33:27 2008
         uid: 0 (root)
         gid: 0 (wheel)
        mode: 104755 (-rwsr-xr-x )
        sha1: <a838b099 24330fe8 d87a89c7 e7b44bfe b0a366cf>

       pkgid: com.apple.pkg.update.os.10.5.3.combo
 pkg-version: 1.0.1.1191932192
install-time: Wed May 28 21:17:57 2008
         uid: 0 (root)
         gid: 0 (wheel)
        mode: 104755 (-rwsr-xr-x )
        sha1: <575abe89 ee144cb7 dfaaa749 1d2f01dd 35e38a66>

       pkgid: com.apple.pkg.update.os.10.5.4.combo
 pkg-version: 1.0.1.1191932192
install-time: Wed Sep  3 18:37:32 2008
         uid: 0 (root)
         gid: 0 (wheel)
        mode: 104755 (-rwsr-xr-x )
        sha1: <cae6dc40 3ef89b9d b1a1defb 994acf13 01ccaf04>

       pkgid: com.apple.pkg.update.os.10.5.5.combo
 pkg-version: 1.0.1.1191932192
install-time: Mon Sep 15 22:24:16 2008
         uid: 0 (root)
         gid: 0 (wheel)
        mode: 104755 (-rwsr-xr-x )
        sha1: <2c865dcf de9932a1 9bb5ae68 31effef1 a095116d>

       pkgid: com.apple.pkg.update.os.10.5.6.combo
 pkg-version: 1.0.1.1191932192
install-time: Tue Dec 16 00:33:52 2008
         uid: 0 (root)
         gid: 0 (wheel)
        mode: 104755 (-rwsr-xr-x )
        sha1: <87ad1e1c a31cb18b 8debe905 1c6a4d3f a6790de1>

       pkgid: com.apple.pkg.update.os.10.5.7.combo
 pkg-version: 1.0.1.1191932192
install-time: Wed May 13 03:05:42 2009
         uid: 0 (root)
         gid: 0 (wheel)
        mode: 104755 (-rwsr-xr-x )
        sha1: <3f03100d 2c6e0fd0 42bafad9 647b15ce 91669189>

       pkgid: com.apple.pkg.update.os.10.5.8.combo
 pkg-version: 1.0.1.1191932192
install-time: Thu Sep  3 12:18:26 2009
         uid: 0 (root)
         gid: 0 (wheel)
        mode: 104755 (-rwsr-xr-x )
        sha1: <c59d0903 a901a3f1 4c5038b7 a4ae0493 65edc2a8>

Please OBSERVE: in the nine *different* versions of Locum listed above, not a single "permission" was ever changed. The file's *contents* did change however, with every update... and that's every bit as important (if not more so) than "permissions" [which is why DU no longer blindly fixes such items. But it doesn't disable them either... so users still need to keep their wits about them].

--

Review:

• earlier versions of DU were exploitable, and actually (potentially) served as a *tool* for hackers.
• Leopard introduced vast new capabilities in OSX to thwart such attacks and enhance security.
• the content of every single *Mac OSX* suid file (past and present) is being tracked.

Quote: Originally Posted by tw It's a bit off-base to assert that DU needs to be 'fixed' because it has a 'bug' because it's not very good at a task it was never designed to do. Even if the problem is fixable (which for reasons I explained previously, I doubt), I cannot see why it would be a priority.

Questions:

• in view of DU's improvements and added capabilies, is that "never designed to do" characterization accurate (or even relevant)?
• who *better* than Apple to take charge of the security of items installed by Mac OSX??

[tw]

Quote: Originally Posted by Hal Itosis ...

dude... whatever! there is obviously no way in hell I'm going to convince you to relax about this, so feel free to freak on it as much as you like without my assistance.

[biovizier]

Quote: Originally Posted by Hal Itosis ...which is why DU no longer blindly fixes such items

I'm still on 10.5, but are you saying they finally fixed this in "Snow Leopard"? That is such a relief.

The most exasperating thing about arguing with the apologists on this subject was the fact that they are generally arguing without any clue whatsoever. Being unable to set them straight while having to tip-toe around the issue of the "repair permissions" flaws to avoid essentially divulging a "how to" on designing a trojan to root a Mac from the default account without a password, and trying to balance the need to educate others of the dangers without making the overall situation worse by increasing awareness of the details has been challenging.

So yes, "repair permissions" in Leopard was a disaster. It refuses to unset a 'setuid' that wasn't supposed to be there. In other words, it refuses to "repair" the permissions, even though it knows they are incorrect, and in a less secure state. "Real world" outcome: People using 10.4 "repair permissions" on a Leopard machine pretty much hosed their system since the wrong files would have the 'setuid' bit set, and 10.5 wouldn't fix them. This included 'launchd', resulting in even "standard" users getting a "Finder" running as "root".

Conversely, despite all of the protestations, 10.5 "repair permissions" would in fact restore the 'setuid' bit on executables even while recognizing that they have been "modified". It basically lies. Since some of those executables were in directories writable by "admin" members AND since "repair permissions" doesn't require authentication when executed from an "admin" account AND since the default account in OS X is "admin", the end result is that "root" is accessible to any process running in an "admin" account.

So "repair permissons" doesn't fix what it should and fixes what it shouldn't.

Earlier versions of "repair permissions" would at least fix what it should (although they were guilty of also fixing what they shouldn't).

Except 10.5's version is worse -- in addition to the "admin" accessible directories, Leopard's "repair permission" also scans for 'setuid' files in world-writable directories so it's actually worse than what came before. While a standard user couldn't get "root" themselves, all they would have to do is put their own file at one of those paths and wait for the "admin" to "repair permissions" and they'd be set.

Such a "standard" user, in designing a smart payload, would probably want to cover their tracks so that the SUID file "has been modified" messages don't keep popping up, but they wouldn't be able to avoid the initial SUID warning (the one that says it won't "repair" the permissions yet goes ahead to actually give the malware 'setuid' and an ownership of "root"). But thanks to TS1448, concerned users asking on a forum about this message will be told that it's safe to ignore the only warning they might actually see that their system has just been "rooted".

The saddest part of all this is that MOAB was pre-Leopard and the developers were obviously working on addressing the issue (the fact that sha1 checks were implemented is an obvious clue, but also note that the permissions on the "a.receiptdb" file don't allow regular users access). But at some higher level, somebody didn't think it was important enough to let them finish, Leopard "repair permissions" has worse security flaws than what it replaced, and throughout the shipping life of Leopard, they still didn't fix it, and encouraged the proliferation of the attitude that modified setuid files aren't anything to be worried about, potentially increasing the effectiveness of anything exploiting the flaws.

That's what the apologists were defending.