Patch for MOAB #9?
shawnce
On Jan 9, 9:33 pm, Landon Fuller <land...@bikemonkey.org> wrote:
> Anyone taken a look at this yet? I just got home.
I hope to get time during lunch or late today to look at this issue...
assuming my normal "daily grind" doesn't get in the way.
-Shawn
Landon Fuller
I haven't had much more time to look at this, but given today's (MOAB
#10) issue, I wonder if the simplest fix isn't also the best fix:
- Turn off "Open safe files"
- Don't open DMGs from untrusted sources
It might also be a good time to throw in Eric Hall's "securing Mac OS
X" links.
What do you think?
-landonf
William A. Carrel
Part of the challenge here is determining how to know if a dmg is safe
outside of trust mechanisms. Would fscking the image before mounting
detect these flaws? (Haven't looked yet, have no idea, maybe fsck
doesn't treat these values safely either.)
--
wac
Augie Fackler
Just tried fsck on the sample exploit dmg - it prints
BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST
ALTERNATE
and then dies on a divide by 0 error. This is on Intel (Core2Duo
Macbook Pro).
So, in any event, if fsck dies trying the check, then we definitely
have a problem...
Augie
>
> --
> wac
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "MOAB Fixes" group.
> To post to this group, send email to moab...@googlegroups.com
> To unsubscribe from this group, send email to moabfixes-
> unsub...@googlegroups.com
> For more options, visit this group at http://groups-beta.google.com/
> group/moabfixes?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
Remy Porter
up a quicky to check the size of the sections used in the exploit? The
whole exploit is built around fiddling with sizes in the header and
making them deviate from standard values- couldn't we whip up a
scanner that would work against this exploit?
--
--------------------------------------
Remy Porter
Geek, artist, and
trouble maker extraordinaire.
If it involves a computer,
and you need it,
he can do it.
--------------------------------------
Landon Fuller
On Jan 10, 2007, at 14:53, Remy Porter wrote:
>
> If we're going so far as to use extra programs to check, can't we whip
> up a quicky to check the size of the sections used in the exploit? The
> whole exploit is built around fiddling with sizes in the header and
> making them deviate from standard values- couldn't we whip up a
> scanner that would work against this exploit?
A Disk Image Validator. That'd be kind of neat.
William A. Carrel
Which should (nearly) be the job of fsck aside from a few headers. If
fsck is crashing on div/0 errors then it needs fixing too.
--
wac
Landon Fuller
Yeah, should be.
I -really- like the idea of a GUI validation tool, I have to say. It
seems a lot saner than trying to insert oneself in either the kernel
or in the disk image framework and attempting to provide validation.
It's also a nice alternative to relying on trust.
-landonf
Matt Beaumont
> A Disk Image Validator. That'd be kind of neat.
I have the start of a Python tool that could be at the core of such a
validator. Right now I'm strictly looking at the issue seen in MOAB 10, but it
should be extensible to further sanity-checking.
-Matt
Landon Fuller
I just committed a simple PyObjC GUI that isn't wired up to anything:
http://moab-fixes.googlecode.com/svn/dmgvalidate/trunk/
Have anything sharable working?
-landonf
Matt Beaumont
> Have anything sharable working?
Hey folks,
I have a simple UFS DMG validator available at
http://lasr.cs.ucla.edu/~mattb/ffs_ck.py
It takes a name of a .dmg as an argument, and passes judgement with regards to
the issue identified in MoAB #10. It's not particularly polished, so I don't
want to hear any bug reports about how it throws an exception if you run it
with no arguments ;)
Landon and I will work on GUIfying it tomorrow.
Cheers,
Matt
st...@info-pull.com
Nice code there. Although, some notes:
print 'frag', hexify(frag)
if frag < 0:
print 'frag invalid: %d < 0' % frag
return False
Why only checking for negative values?
The issue here is making it wrap to a specific value lower than the
amount of bytes we want to be copied from our DMG image for abusing a
heap-based buffer overflow. The kernel won't allocate a negative size
buffer (the proof of concept image shows that right away...), but it
doesn't mind about allocating 150 bytes and then copying >400 over it.
Thus that approach is not effective. You're making the usual mistake of
working against the available exploit, and not the vulnerability
itself.
A 'validator' for DMG images will have to support and understand the
underlying format of the filesystems that can be encapsulated, and
considering the amount of supported ones it sounds like overkill
approach. Interesting as an experiment, definitely.
Now, Python is evil... that code looks nice in Ruby :-)
On Jan 11, 8:20 am, Matt Beaumont <m...@cs.ucla.edu> wrote:
> On Wed, Jan 10, 2007 at 20:35:14 -0800, Landon Fuller wrote:
> > Have anything sharable working?Hey folks,
Matt Beaumont
> Thus that approach is not effective. You're making the usual mistake of
> working against the available exploit, and not the vulnerability
> itself.
I was definitely aware that I was doing this yesterday, but I was more
focused on getting a POC tool (as it were) available than on writing
something comprehensive and bulletproof. Obviously, the UFS superblock
parsing that the tool currently does is very ad hoc, and there are many
more fields and combinations of fields that should be checked.
> A 'validator' for DMG images will have to support and understand the
> underlying format of the filesystems that can be encapsulated, and
> considering the amount of supported ones it sounds like overkill
> approach.
As a third party, trying to write a comprehensive validator would indeed
be overkill. It's Apple's responsibility to code defensively in the
actual DMG and filesystem handling modules. However, I think that
validating with respect to known vulnerabilities (in a more robust way
than my code currently does) is a reasonable goal.
Cheers,
Matt
st...@info-pull.com
> It's Apple's responsibility to code defensively in the
> actual DMG and filesystem handling modules. However, I think that
> validating with respect to known vulnerabilities (in a more robust way
> than my code currently does) is a reasonable goal.
Well, UFS is all legacy from FreeBSD. This is what happens when you
copy or use others' work without actually walking through it for
potential mistakes. Probably one of the main reasons that makes OS X
more prone to 'exposure' than software from other vendors. Apple has
glued all-together their technology to that of many other people, and
more important, from certainly different time-frames. Thus they have to
do much more than just fix their own mistakes to deliver a working
'patch'.
Try to read the AppleTalk source code (kernel-land). It's like someone
'plastered' it in the first place it seemed to fit. ;-)
DMG itself is nothing but a meta-format. It happens to be flawed by
design, but we aren't the first ones to say it. Even those who happily
attack the MoAB and related parties, have talked in the past that it
was a huge mistake by Apple. It's a greatly useful feature, but the
security implications are probably enough to justify it's removal until
some kind of QA is done around the related source code and components.
That QA is missing, as of today. Or they simply rely on the FreeBSD
developers to the job for them, for free.
Cheers.
Remy Porter
that Google has released a version of FUSE for the Mac (File System in
User Space) which takes FS management out of the kernel. This wouldn't
resolve the DMG problem, but if we loaded the file system in user
space, couldn't we minimize the impact of exploits at least? Or would
the use of something like FUSE just add to the risks.
//I'm mostly hanging out here for the educational value, so tell me if
I'm sounding like an idiot.
alas...@coriolis-systems.com
> Well, UFS is all legacy from FreeBSD. This is what happens when you
> copy or use others' work without actually walking through it for
> potential mistakes. Probably one of the main reasons that makes OS X
> more prone to 'exposure' than software from other vendors.
AFAIK UFS is legacy code from NeXTStep, not FreeBSD. That's why the UFS
filesystem format it uses is the NeXT variant, not the normal BSD
version.
> DMG itself is nothing but a meta-format. It happens to be flawed by
> design,
The DMG idea isn't "flawed by design", though it's true that it might
be better to use a file-based metaformat rather than a filesystem
metaformat for software distribution.
> It's a greatly useful feature, but the
> security implications are probably enough to justify it's removal until
> some kind of QA is done around the related source code and components.
> That QA is missing, as of today. Or they simply rely on the FreeBSD
> developers to the job for them, for free.
I suppose you think Apple do no QA at all...
Regards,
Alastair.
st...@info-pull.com
On Jan 12, 5:54 pm, alast...@coriolis-systems.com wrote:
> On Jan 11, 6:29 pm, s...@info-pull.com wrote:
>
> AFAIK UFS is legacy code from NeXTStep, not FreeBSD. That's why the UFS
> filesystem format it uses is the NeXT variant, not the normal BSD
> version
XNU ("Apple's") bsd/ufs/ffs/ffs_alloc.c:
22 /* Copyright (c) 1995 NeXT Computer, Inc. All Rights Reserved */
23 /*
24 * Copyright (c) 1982, 1986, 1989, 1993
25 * The Regents of the University of California. All rights
reserved.
(...)
FreeBSD ufs/ffs/ffs_alloc.c:
1 /*-
2 * Copyright (c) 2002 Networks Associates Technology, Inc.
3 * All rights reserved.
(...)
31 *
32 * Copyright (c) 1982, 1986, 1989, 1993
33 * The Regents of the University of California. All rights
reserved.
---
XNU:
2 * Copyright (c) 2000-2003 Apple Computer, Inc. All rights
reserved.
3 *
4 * @APPLE_LICENSE_HEADER_START@
5 *
...
22 /* Copyright (c) 1995 NeXT Computer, Inc. All Rights Reserved */
23 /*
24 * Copyright (c) 1982, 1986, 1993
25 * The Regents of the University of California. All rights
reserved.
FreeBSD:
1 /*-
2 * Copyright (c) 1982, 1986, 1993
3 * The Regents of the University of California. All rights
reserved.
(...)
http://fxr.watson.org/fxr/source/ufs/ffs/fs.h
http://fxr.watson.org/fxr/source/bsd/ufs/ffs/fs.h?v=xnu-792
(...)
Look over them, it's not necessary to call a SCO rogue squadron for
showing that they share code. Well, most of it.
And of course, Apple added some flaws of it's own to the mix.
> The DMG idea isn't "flawed by design", though it's true that it might
> be better to use a file-based metaformat rather than a filesystem
> metaformat for software distribution.
Not flawed by design? Could you please support that statement with
technical details about how they've implemented it?
Let's see:
1. Let *unprivileged* users mount arbitrary filesystem streams, which
expose low-level kernel interfaces.
2. Let the DMG image decide where to load the different streams without
first validating them (ala TIFF fiasco).
3. Support ancient code directly involved in handling of certain DMG
supported filesystems: UFS.
22 /* Copyright (c) 1995 NeXT Computer, Inc. All Rights Reserved */
23 /*
24 * Copyright (c) 1982, 1986, 1989, 1993
25 * The Regents of the University of California. All rights
reserved.
(...)
4. Don't bother validating the encapsulated fs streams either. "That's
BSD code task, not our job".
Now, please tell us what we are missing there, because from the
security perspective, DMG is jackass.
I agree that using a regular package format would be the way to go.
Although I don't have experience to talk about that particular matter.
I have very briefly worked with RPM and some other package engines and
always found them overcomplicated (Gentoo for instance, with their
portage tree, and the usual BSD distribs. got the package management
idea right, IMHO).
> I suppose you think Apple do no QA at all...
"That QA is missing, as of today". We're not talking about the kind of
QA you are thinking about, maybe. We don't care about a dialog which
doesn't update a progress bar properly. We care for the problem that
makes someone pop a shell in your system. Different scenarios,
Alastair.
If they did a minimal security QA they would be far more consistent
against the typical issues. Even the most simple entry point bugs
affect OS X.
Cheers.
Alastair
> On Jan 12, 5:54 pm, alast...@coriolis-systems.com wrote:
>
> > On Jan 11, 6:29 pm, s...@info-pull.com wrote:
>
> > AFAIK UFS is legacy code from NeXTStep, not FreeBSD. That's why the UFS
> > filesystem format it uses is the NeXT variant, not the normal BSD
> Look over them, it's not necessary to call a SCO rogue squadron for
> showing that they share code. Well, most of it.
> And of course, Apple added some flaws of it's own to the mix.
You said that they got it from FreeBSD. You were wrong, and you are
still wrong. They got it from NeXT. It's true that NeXTStep, FreeBSD
and many of the other BSD variants got the code from the original BSD
distribution(s). But what you've said doesn't make a blind bit of
difference to the fact that the code came from NeXTStep.
You were attempting, I think, to suggest that Apple are freeloading on
the back of FreeBSD, which is not true, even for the bits of code that
did come from FreeBSD (and there is quite a lot that doesn't; a lot of
the code comes either from NeXTStep or from MkLinux, or has been
written subsequently by people at Apple or NeXT).
> > The DMG idea isn't "flawed by design", though it's true that it might
> > be better to use a file-based metaformat rather than a filesystem
> > metaformat for software distribution.
>
> Not flawed by design? Could you please support that statement with
> technical details about how they've implemented it?
Yes, sure. The only reason DMGs are problematic is that the kernel code
for filesystems might contain bugs. Which makes all removable media
problematic, incidentally, since users can insert all kinds of
removable devices with all sorts of filesystems on them.
That doesn't make DMGs "flawed by design", any more than a floppy disk
or a USB memory stick is "flawed by design" for the same reason. The
fact is that kernel filesystem code already has to be secure, and
actually it's more secure than you keep implying because a few of the
bugs you've found are not (as you have claimed) prone to exploitation,
and certainly not to remote exploitation since disk images are a local
feature. You already need access to the machine, or you need some
social engineering, just as with any other local attack vector. Even if
you claim it's possible for a website to automatically download and
mount a DMG (and I'll even let you use Safari, with the Open safe files
feature enabled), you still need to get a user to go to that site.
It's true, as I've said, that there is something to be said for the
idea of storing a collection of files rather than a raw filesystem.
But, equally, there are things that you can only do if a DMG is an
image of a disk (for instance, it's very useful for imaging
filesystems...)
Regards,
Alastair.
Finlay Dobbie
> You were attempting, I think, to suggest that Apple are freeloading on
> the back of FreeBSD, which is not true, even for the bits of code that
> did come from FreeBSD
It's impossible to freeload off FreeBSD, really - that would imply
that you are "taking advantage" of them. The license *encourages* the
utilisation of their code. Apple frequently does so, and this is a
good thing.
> Yes, sure. The only reason DMGs are problematic is that the kernel code
> for filesystems might contain bugs. Which makes all removable media
> problematic, incidentally, since users can insert all kinds of
> removable devices with all sorts of filesystems on them.
You require physical access to a machine to insert removable media,
you do not require physical access to a machine to mount a disk image.
This makes them fundamentally more dangerous.
> That doesn't make DMGs "flawed by design", any more than a floppy disk
> or a USB memory stick is "flawed by design" for the same reason.
Well, I'd argue that encouraging the use of DMGs for software
distribution is a bit silly. Especially considering they encourage
"internet-enabled" disk images, which basically then just means
they're another archival format. Why encourage an archive format which
exposes critical kernel filesystem code when there are plenty of other
archive formats which run only in userspace? It just doesn't make an
awful lot of sense to me.
There is a valid point here. These are serious bugs, and the decisions
made about the approaches taken do highlight serious concerns about
the general awareness of security issues and suchlike within Apple
engineering.
It's easy to attack the manner in which MoAB have handled themselves,
and obviously there are valid concerns with their competence as well
as their professionalism. It's unfortunate, as the result is that
they've queered their own pitch and undoubtedly diluted the impact
that they were aiming for. I was looking forward to MoAB for a good
dose of reality, but unfortunately it almost immediately deterioriated
into a shit-slinging match between fanboys and zealots of one kind or
another, which has pretty much precluded any mature debate.
-- Finlay
antibozo
up twice.
On Jan 13, 9:20 am, "Alastair" <alast...@alastairs-place.net> wrote:
> Yes, sure. The only reason DMGs are problematic is that the kernel code
> for filesystems might contain bugs.
Not necessarily the only reason. One wonders what mount options are
employed when these filesystems are mounted. "nosuid" and "nodev" would
hopefully be among them. Does anyone know?
> Which makes all removable media
> problematic, incidentally, since users can insert all kinds of
> removable devices with all sorts of filesystems on them.
Only with physical access to the system, in which case all bets are off
anyway.
I have to agree with the critics--exposing kernel filesystem code
directly to downloaded, untrusted content, without even checking a
signature (let alone running fsck), is a really, really bad design.
It isn't as if things like RPM haven't been around for years to serve
as an example of how to distribute an installation package with
internal integrity checks and digital signatures. One wonders what
planet Apple was on then they thought DMG was a good idea.
anti...@gmail.com
> for filesystems might contain bugs.
Um, not necessarily the only reason. One wonders what mount options are
employed when these filesystems are mounted. "nosuid" and "nodev" would
hopefully be among them. Anyone know?
> Which makes all removable media
> problematic, incidentally, since users can insert all kinds of
> removable devices with all sorts of filesystems on them.
Yes, with physical access to the machine. But I have to agree with the
critics who say that directly exposing kernel filesystem code to
downloaded, untrusted content without even checking a signature (let
along running fsck), is a really, really bad design. I would go so far
as to call it stupid.
It's not as if things like RPM haven't been around for years to serve
as examples of how to roll an installation package with internal
integrity checks and digital signatures. One wonders what planet Apple
was on when they thought DMG was a good idea.
> Even if
> you claim it's possible for a website to automatically download and
> mount a DMG (and I'll even let you use Safari, with the Open safe files
> feature enabled), you still need to get a user to go to that site.
Um, gee, that's difficult. Am I allowed to use XSS? Or do I have to
make a page that just looks interesting?
Landon Fuller
On Jan 13, 11:21 am, antib...@gmail.com wrote:
> On Jan 13, 9:20 am, "Alastair" <alast...@alastairs-place.net> wrote:
>
> > Yes, sure. The only reason DMGs are problematic is that the kernel code
> > for filesystems might contain bugs.
> Um, not necessarily the only reason. One wonders what mount options are
> employed when these filesystems are mounted. "nosuid" and "nodev" would
> hopefully be among them. Anyone know?
Implementation here:
http://fxr.watson.org/fxr/source/bsd/vfs/vfs_syscalls.c?v=xnu-792.6.70#L173
Non-root restrictions:
- Only allow root, or the original mounting user, to update a mount
point
- If !root, force nosuid and nodev
- If !root, and file system was originally mounted noexec, force
noexec on update
- If !root, user must own the mount point
> > Even if
> > you claim it's possible for a website to automatically download and
> > mount a DMG (and I'll even let you use Safari, with the Open safe files
> > feature enabled), you still need to get a user to go to that site.
With Safari's "Safe Files" feature, this is sufficient:
http://landonf.bikemonkey.org/static/moab-tests/autodmg.html
Here's an example of a QuickTime HREFTrack calling javascript (MoAB
issue discovered by Aviv Raff):
http://landonf.bikemonkey.org/static/moab-tests/hreftrack.html
Unfortunately, cross-site/zone attacks, such as the QuickTime above,
have been proven as viable propagation methods in the past:
http://www.websense.com/securitylabs/alerts/alert.php?AlertID=708
While there are no doubt difficulties to exploiting some of the DMG
issues remotely, delivering the corrupt DMG to Safari users with the
default settings seems very workable.
William A. Carrel
>
> Hm, the dog appears to have eaten my earlier reply. Sorry if this shows
> up twice.
My apologies for these problems. :-(
I suspect they were on the planet "fast random access". RPM, zip, tar,
cpio,... all of these do sequential access well, but not random
access. Of course, all you have to do to speed up random access is
walk the file, save the individual file offsets into some cache
structure (or dare I say filesystem structure).
And then to save processing for clients you could attach that
structure to the file format somehow for easy re-use in the future.
And then people can fuzz that structure just like the filesystem
structures. Although one would hope such processing would be in
userland.
I'm still of a mind that untrusted filesystems of any sort
(diskimages, physical CDs/disks, whatever...) should be throroughly
checked for consistency before being used. The additional concern here
is that dmg loading is automatable with default settings if you can
get users to point at the browser. If these problems exist in the UFS
code, they probably exist in the ISO9660 code, and the HFS+ code.
fsck is normally the tool used for sanity-checking filesystems. It
should be able to handle casual random damage as well as targeted
malicious damage. In these cases it dies with divide by zero errors
because of commented out lines of code, which is pretty sad.
http://www.opensource.apple.com/darwinsource/10.4.8.x86/diskdev_cmds-332.18/fsck.tproj/setup.c
Search for "#warning fix this" for an example. :-/
--
wac
antibozo
> On 1/13/07, antibozo <antib...@gmail.com> wrote:
> > One wonders what
> > planet Apple was on then they thought DMG was a good idea.
> I suspect they were on the planet "fast random access". RPM, zip, tar,
> cpio,... all of these do sequential access well, but not random
> access. Of course, all you have to do to speed up random access is
> walk the file, save the individual file offsets into some cache
> structure (or dare I say filesystem structure).
Okay, I can imagine them thinking fast random access to the archive was
worth the cost in wasted space due to blocking and dangerous exposed
code paths in the kernel, for the 20 or so seconds it might take before
they figured out that they could, you know, unpack a tar or cpio file
to achieve the same thing in userland. :^)
> And then to save processing for clients you could attach that
> structure to the file format somehow for easy re-use in the future.
> And then people can fuzz that structure just like the filesystem
> structures. Although one would hope such processing would be in
> userland.
No need for all that. Like I say, just unpack it. A better package
strategy is along these lines:
Package consists of a tar or cpio archive containing all needed files
and directories, along with a manifest specifying ownership,
permissions, and digest for every object in the archive, other metadata
including package name, version, release, platform/architecture, any
pre- and post-install scripts, all of that optionally signed with GPG.
This is pretty much what RPM is.
> fsck is normally the tool used for sanity-checking filesystems. It
> should be able to handle casual random damage as well as targeted
> malicious damage. In these cases it dies with divide by zero errors
> because of commented out lines of code, which is pretty sad.
I fully agree. Seems to me Apple folks didn't understand the dual
purpose of fsck. The first purpose, which they got, is to recover
filesystems and clean up inconsistencies due to a crash. The second
purpose, of equal importance, is to protect the kernel from crashing
due to bogus data structures in the filesystem. Having the kernel
double-check every little thing for consistency in a mounted filesystem
is too costly, so most of that is supposed to be taken care of by fsck
before mount. Fixing fsck to do its job properly and using it before
mounting a filesystem stream from a DMG could effectively solve this
problem, as long as there are no race conditions allowing the
filesystem stream to be swapped out between fsck and mount.
But it's a lot of work to rescue a poor design. They should just go
read up on RPM. Even dpkg would be better than what they've got.
antibozo
> On Jan 13, 11:21 am, antib...@gmail.com wrote:
> > One wonders what mount options are
> > employed when these filesystems are mounted. "nosuid" and "nodev" would
> > hopefully be among them. Anyone know?
> Implementation here:
Landon,
Thanks for the informative followup.
antibozo
> Fixing fsck to do its job properly and using it before
> mounting a filesystem stream from a DMG could effectively solve this
> problem, as long as there are no race conditions allowing the
> filesystem stream to be swapped out between fsck and mount.
On second thought, fsck can't solve this at all. There's always a race
condition.
Assume the DMG filesystem stream is fully inspected by fsck and
whatever else you might throw at it, and comes up clean. The stream is
then mounted as a filesystem, and an installation process is started.
Once you start executing a script out of the mounted filesystem stream,
that script can open up the filesystem stream itself and modify it in
place. So even though the things looks clean, the subsequent install
process can modify data structures in the filesystem stream to exploit
vulnerabilities in the kernel's filesystem code. Solving this is, I
think, equivalent to solving the halting problem.
There's a reason block device nodes are not writable by regular users.
Landon Fuller
On Jan 13, 2007, at 10:14 PM, antibozo wrote:
> But it's a lot of work to rescue a poor design. They should just go
> read up on RPM. Even dpkg would be better than what they've got.
An archive format would probably be a much more suitable solution for
software distribution, but moving to a full-blown packaging system
does not really mesh with the "drag the application to the
Application folder" installation paradigm.
-landonf
antibozo
> An archive format would probably be a much more suitable solution for
> software distribution, but moving to a full-blown packaging system
> does not really mesh with the "drag the application to the
> Application folder" installation paradigm.
Well, Windows manages to make ZIP archives look like folders in the
explorer; I should think taking this approach in the Finder could cover
that paradigm. I guess the FUSE approach mentioned by others is a
similar notion.
I'm a little out of my depth here, since I don't use Mac OS much and I
don't have a Mac. So I may be missing some of the intended uses for the
DMG model.
Toad
:)
Toad
Matt Beaumont
> Hows the dmgvalidate program coming?
> :)
Poorly. Don't have an Intel Mac with which to poke at the wrong-endian
issues in MoAB 11, and the last two bugs are outside of the superblock.
Like Mr Carrel said, fsck is supposed to catch these things, but OS X's
fsck is in something of a broken state. At this point I'm sort of
thinking that it might be worth my time to hack on fsck until it does
its job properly, but I haven't really looked into it.
Cheers,
Matt
William A. Carrel
You're right. The filesystem mounting code has to make the exact same
sanity checks and give up the attempt if things look off. fsck
hopefully could gain the ability to fix these structures back to
reasonably sane values. That is, fsck can only protect against a
passive adversary that sends a malware dmg, but has no other access to
the system. An active adversary executing code on the system can use
this as a trampoline into potentially running arbitrary code in the
kernel.
By the time the filesystem is mounted, these structures should be in
memory so overwriting them in the underlying device shouldn't be a big
deal. Still, this might make an interesting avenue of attack since
everything else that's coming off the disk needs to be sanity checked
as well. It certainly does not look like that's universally the case.
DMG just provides additional automation for this attack. There's
nothing keeping Mallory from walking up to Steve's unattended but
locked laptop, plugging a USB disk in, and subverting the screen lock,
the FileVault passwords, and anything else with a specially crafted
filesystem. Due to the disk automounter, it's a glaring vulnerability
even without DMG to help things along. Another example, mailing out
CDs with this sort of malware presuming ISO9660's filesystem code has
related issues. This could hit Windows and Linux as well. (No Sony, I
won't write this for you, please stop calling.)
Loopback mounts on Linux/*BSD would be similarly vulnerable to this
kind of attack. Forcing untrusted disks to mount with something like
FUSE could do a lot for security in these cases since the filesystem
code couldn't take the kernel with it.
--
wac
Alastair
> On Jan 13, 5:30 pm, "William A. Carrel" <willia...@carrel.org> wrote:
>
> Seems to me Apple folks didn't understand the dual
> purpose of fsck. The first purpose, which they got, is to recover
> filesystems and clean up inconsistencies due to a crash. The second
> purpose, of equal importance, is to protect the kernel from crashing
> due to bogus data structures in the filesystem. Having the kernel
> double-check every little thing for consistency in a mounted filesystem
> is too costly, so most of that is supposed to be taken care of by fsck
> before mount.
That's a little disingenuous, don't you think? There's no need for the
kernel to check everything for consistency, but there is still a basic
requirement that filesystem code shouldn't cause kernel panics or allow
the system to be compromised somehow. I don't think you can sensibly
claim that fsck should bear all the responsibility for that, or that
Apple (or any other software company that writes system kernels) are
totally ignorant of the problem.
> But it's a lot of work to rescue a poor design. They should just go
> read up on RPM. Even dpkg would be better than what they've got.
But there are commonly bugs in packaging systems. Isn't one of the
other MoAB bugs just such a thing, in fact? And packaging system bugs
can be just as damaging security-wise as a full-blown kernel bug.
I think the benefits of e.g. RPM are being over-stated by those opposed
to DMG. As I've said, I don't think DMGs are perfect and there are
certainly things that could be done to make them safer (for instance,
restricting the set of filesystems that were allowable in a DMG that
was mounted from Finder or Safari would be a good start, as would
creating a very simple "filesystem" that was basically just a list of
files and sizes and that wasn't as prone to compromise as a real
filesystem).
Kind regards,
Alastair.
antibozo
> On Jan 14, 6:14 am, "antibozo" <antib...@gmail.com> wrote:
> > Having the kernel
> > double-check every little thing for consistency in a mounted filesystem
> > is too costly, so most of that is supposed to be taken care of by fsck
> kernel to check everything for consistency, but there is still a basic
> requirement that filesystem code shouldn't cause kernel panics or allow
> the system to be compromised somehow.
Disingenuous? Not at all.
Preventing kernel panics in the attack scenario I described would
require checking a lot of things and, I suspect, adding a lot of mutex
calls. What can you safely trust in a filesystem? Which operations do
you need to make atomic to avoid following a null or bogus pointer if a
process overwrites an inode block in the middle of an operation (and
allocates enough memory to push the block out of cache)? If you do
manage to identify all the potential race conditions and protect them
with atomicity, what happens to your filesystem performance?
> I don't think you can sensibly
> claim that fsck should bear all the responsibility for that, or that
> Apple (or any other software company that writes system kernels) are
> totally ignorant of the problem.
Generally speaking, filesystem code is not written defensively against
targeted attacks of this kind. It *is* the responsibility of fsck to
provide that defense, and fsck can only do that before mount occurs.
Any system that allows a regular user to modify an already mounted
filesystem's backing store is going to have to signficantly remediate a
lot of filesystem code to resist this form of attack. Most OSes only
allow regular users to mount locally parsed filesystems when physical
access has been demonstrated. This is a form of attack that can be
conducted remotely, regardless of DMG handling--once malware is in
control, it can create a fake filesystem on the fly and mount it.
That's the feature that is really broken about all this--regular users
shouldn't be able to mount locally parsed filesystems, especially if
they can write to the backing store, without proving physical access.
> > But it's a lot of work to rescue a poor design. They should just go
> > read up on RPM. Even dpkg would be better than what they've got.
> But there are commonly bugs in packaging systems. Isn't one of the
> other MoAB bugs just such a thing, in fact? And packaging system bugs
> can be just as damaging security-wise as a full-blown kernel bug.
Speaking of disingenuous... ;^)
Yes, of course packaging systems have bugs. GNU tar itself just had a
bug a few weeks ago. The quite clear difference is that patching those
is a simple matter of patching a userland program (and usually a very
minor change, like the size of a buffer or some simple boundary test),
while patching this is a matter of identifying every place in the
kernel where crafted filesystem data structures can cause a problem.
This is an extremely complex problem that results from weak design, not
a simple bug.
> I think the benefits of e.g. RPM are being over-stated by those opposed
> to DMG. As I've said, I don't think DMGs are perfect and there are
> certainly things that could be done to make them safer (for instance,
> restricting the set of filesystems that were allowable in a DMG that
> was mounted from Finder or Safari would be a good start, as would
> creating a very simple "filesystem" that was basically just a list of
> files and sizes and that wasn't as prone to compromise as a real
> filesystem).
As I mentioned earlier, if Microsoft can make ZIP archives look like
folders, Apple could easily do the same. There's no need for users to
call mount(2) at all for this problem.
Those of us who are accustomed to being able to trust packages based on
signatures are admittedly unimpressed by something as poorly thought
out as DMG. Other benefits of a good packager, such as being able to
verify that all files have original permissions and content, determine
easily which configuration files have been customized, update a package
and have the installer automatically refrain from overwriting
customized configs, determine exactly which version of a package is
installed, when it was installed, who built it and when it was
built--the list goes on and on--make it obvious that DMG is not even
attempting to solve any serious problem. As an infrequent Mac OS user,
I can only assume that Mac OS must provide some other serious package
management system, and DMG is just a convenience add-on that no one at
Apple thought about for very long.
Bottom line for me: it simply blows my mind that Apple thought that
mounting a downloaded filesystem, without assurance of *any* kind that
it was intact, would be a "safe" thing to do. This is a real failure in
concept and it ought to be removed from Mac OS completely, along with
the ability for remote regular users to mount any locally parsed
filesystem from a backing store under their own control.
Dag Ågren
> Those of us who are accustomed to being able to trust packages based on
> signatures are admittedly unimpressed by something as poorly thought
> out as DMG.
Signatures don't mean much if you don't get all your software from a
centralized repository. Those of us who like distributing our own
software are pretty unimpressed with such centralization, too.
antibozo
> Signatures don't mean much if you don't get all your software from a
> centralized repository. Those of us who like distributing our own
> software are pretty unimpressed with such centralization, too.
On the contrary--signatures enable decentralization of package
distribution. You can sign your own packages and then people who
download them can check to see if they're authentic no matter where
they download them from. And if you don't feel like signing them, you
don't have to, but the facility is there for those who do.
Remember the trojaned distribution of tcp_wrappers?
Landon Fuller
It's a tough call, given that fsck could very easily have serious
issues too. Add chroot and setuid to fsck? =)
I just committed code that hooks the DIDiskImageAttach call, and
William Carrel and I dissected all the arguments:
uint32_t DIHLDiskImageAttach(CFDictionaryRef imageDict, void
*statusCallback, void *statusContext, CFDictionaryRef **pmap);
Using the first argument, it's be possible to implement pre-mount
validation (fsck, python script, or otherwise):
<NSCFDictionary 0xd260940>{
main-url = file://localhost/Users/landonf/Desktop/safe.dmg.download/
safe.dmg;
mounting-agent = safari;
}
Currently, the code just displays a warning dialog ("Keep kids off
DMGs!") and asks the user's permission before passing the require to
the DiskImages framework.
http://moab-fixes.googlecode.com/svn/trunk/dmgwarn_handler.c
Might be worth wiring something up?
-landonf
William A. Carrel
>
> On Jan 14, 2007, at 12:44 AM, Matt Beaumont wrote:
>
> >
> > On Sat, Jan 13, 2007 at 23:36:07 -0800, Toad wrote:
> >> Hows the dmgvalidate program coming?
> >> :)
> >
> > Poorly. Don't have an Intel Mac with which to poke at the wrong-endian
> > issues in MoAB 11, and the last two bugs are outside of the
> > superblock.
> > Like Mr Carrel said, fsck is supposed to catch these things, but OS
> > X's
> > fsck is in something of a broken state. At this point I'm sort of
> > thinking that it might be worth my time to hack on fsck until it does
> > its job properly, but I haven't really looked into it.
>
> It's a tough call, given that fsck could very easily have serious
> issues too. Add chroot and setuid to fsck? =)
fsck definitely does have issues that make it way less than
trustworthy. It also wants access to the (virtual) disk block device
to check if the superblock values look sane wrt the partition.
Basically we'd need to:
- do the image attach with mount-required = false, mount-attempted = false
- run Matt's script on the image
- figure out what kind of filesystem it is
- run the appropriate fsck on the image (safely somehow...)
- show results, warn the user anyway
- if user says okay, actually mount the image that we only attached before
- if user says no, detach the image
Of course, all this doesn't protect against an active adversary trying
to fuzz the filesystem after the scripts check it for naughty values.
The only protection for that is a lot more error checking in the
kernel or do all the disk image mounts in FUSE (and hope that it has
better resilience when things go haywire).
Landon Fuller
On Jan 14, 2007, at 10:57 PM, William A. Carrel wrote:
>
> On 1/14/07, Landon Fuller <lan...@bikemonkey.org> wrote:
>>
>> It's a tough call, given that fsck could very easily have serious
>> issues too. Add chroot and setuid to fsck? =)
>
> fsck definitely does have issues that make it way less than
> trustworthy. It also wants access to the (virtual) disk block device
> to check if the superblock values look sane wrt the partition.
>
> Basically we'd need to:
> - do the image attach with mount-required = false, mount-attempted
> = false
> - run Matt's script on the image
> - figure out what kind of filesystem it is
DI framework can tell us this via the partition map argument to
DLHLDiskImageAttach():
(gdb) po $eax
<NSCFDictionary 0x325720>{
system-entities = <NSCFArray 0x324cc0>(
<NSCFDictionary 0x321fc0>{
content-hint = Apple_partition_scheme;
dev-entry = /dev/disk3;
},
<NSCFDictionary 0x326290>{
content-hint = Apple_partition_map;
dev-entry = /dev/disk3s1;
},
<NSCFDictionary 0x3262f0>{
content-hint = Apple_HFS;
dev-entry = /dev/disk3s2;
}
);
}
> - run the appropriate fsck on the image (safely somehow...)
Or not safely, if this is disabled by default and it's up to the user
to decide.
> - show results, warn the user anyway
> - if user says okay, actually mount the image that we only attached
> before
> - if user says no, detach the image
The code to display a warning and abort the mount is ready to go.
> Of course, all this doesn't protect against an active adversary trying
> to fuzz the filesystem after the scripts check it for naughty values.
> The only protection for that is a lot more error checking in the
> kernel or do all the disk image mounts in FUSE (and hope that it has
> better resilience when things go haywire).
Which is probably far outside the scope of what we should be playing
with.
It seems like the TODOs are:
- Add preferences for disk validation
- Decide on a means of validating the disk (eg, matt's script, fsck,
both?).
- Insert validation code into the disk mounting path.
As a brief introduction, the private framework function I'm patching
is DIHLDiskImageAttach. It takes four arguments and returns an OSStatus:
OSStatus DIHLDiskImageAttach(CFDictionaryRef imageDict, void
*statusCallback, void *statusContext, CFDictionaryRef *pmap);
The imageDict argument accepts a number of options, eg:
<NSCFDictionary 0x317720>{
mount-attempted = 0;
mount-required = 0;
image-options = <NSCFDictionary 0x317690>{
};
debug = 0;
verbose = 0;
quiet = 0;
agent = hdiutil;
main-url = file://localhost/Users/landonf/Desktop/safe.dmg;
drive-options = <NSCFDictionary 0x3178c0>{
};
}
"main-url" and "agent" (or "mounting-agent", not sure of the
difference yet) appear to be the only required options.
The statusCallback accepts two arguments: context, and (IIRC, I
misplaced my notes on this) an integer mount state. statusContext can
be a pointer to anything.
pmap accepts a (CFDictionary **) argument, and is set by
DIHLDiskImageAttach to point at a new CFDictionary:
<NSCFDictionary 0x325720>{
system-entities = <NSCFArray 0x324cc0>(
<NSCFDictionary 0x321fc0>{
content-hint = Apple_partition_scheme;
dev-entry = /dev/disk3;
},
<NSCFDictionary 0x326290>{
content-hint = Apple_partition_map;
dev-entry = /dev/disk3s1;
},
<NSCFDictionary 0x3262f0>{
content-hint = Apple_HFS;
dev-entry = /dev/disk3s2;
}
);
}
I'm not sure of the ownership of that dictionary.
-landonf
Alastair
>
> Seems to have been eaten by the google monster, resending.
New posts don't seem to show-up immediately every time. I imagine
there's a server farm and some sort of replication going on behind the
scenes. Anyway.
> On Jan 14, 2007, at 10:57 PM, William A. Carrel wrote:
>
> > On 1/14/07, Landon Fuller <land...@bikemonkey.org> wrote:
>
> > Basically we'd need to:
> > - do the image attach with mount-required = false, mount-attempted
> > = false
> > - run Matt's script on the image
> > - figure out what kind of filesystem it isDI framework can tell us this via the partition map argument to DLHLDiskImageAttach():
> > - run the appropriate fsck on the image (safely somehow...)Or not safely, if this is disabled by default and it's up to the user
> to decide.
> > - show results, warn the user anyway
> > - if user says okay, actually mount the image that we only attached
> > before
> > - if user says no, detach the imageThe code to display a warning and abort the mount is ready to go.
I'm not sure about all this. The thing is that it still won't protect
against some modes of attack, which leads me to ask what the benefit is
actually going to be.
Surely the point of the MoAB fixes project is to provide a timely fix,
like a sticking plaster, and to let Apple spend the time on fixing
things properly? To my mind, this is heading rapidly away from that.
Might it not be better to provide a kernel patch to add the necessary
checks to prevent the bugs that have been reported? I think we can
reasonably assume that Apple won't release many more kernel updates
before these get fixed, which might help.
Kind regards,
Alastair.
antibozo
> New posts don't seem to show-up immediately every time.
I've had one post in this thread be delayed by an hour or so, and
another never show up at all, even though Google claimed the post was
successful (sometimes it says posting failed, try again later). I didn'
t bother reposting as the material got covered elsewhere.
So save your posts, but give it an hour or so before reposting.
Matt Beaumont
> >Of course, all this doesn't protect against an active adversary trying
> >to fuzz the filesystem after the scripts check it for naughty values.
> >The only protection for that is a lot more error checking in the
> >kernel or do all the disk image mounts in FUSE (and hope that it has
> >better resilience when things go haywire).
>
> Which is probably far outside the scope of what we should be playing
> with.
Agreed.
> It seems like the TODOs are:
> ...
> - Decide on a means of validating the disk (eg, matt's script, fsck,
> both?).
My script is a hack. The checks it does should be added to fsck. (Carefully,
of course, given that fsck is going to be doing all of its math mod 2^32.)
-Matt
William A. Carrel
Posts, especially those that come from addresses not subscribed to the
list, are sometimes held for moderation, which can appear as a delay.
--
wac
Landon Fuller
On Jan 15, 2007, at 1:48 PM, Alastair wrote:
> I'm not sure about all this. The thing is that it still won't protect
> against some modes of attack, which leads me to ask what the
> benefit is
> actually going to be.
That's true. It protects against the remote, accidental vector, but
not against every possible vector, especially local ones.
>
> Surely the point of the MoAB fixes project is to provide a timely fix,
> like a sticking plaster, and to let Apple spend the time on fixing
> things properly? To my mind, this is heading rapidly away from that.
Indeed; I've stewed over the issue for a few days now. Here's my
general breakdown:
- Patching the kernel is a high-risk proposition.
- If we don't patch the kernel, we can't provide a *simple* "sticking
plaster" fix.
- If we insert ourselves into the Disk Images framework, we can
mitigate some of the more serious vectors
My primary issue with this solution is that this heads rapidly down
the road to complexity, leaving me to wonder if "be careful about
disk images" isn't the better strategy.
> Might it not be better to provide a kernel patch to add the necessary
> checks to prevent the bugs that have been reported? I think we can
> reasonably assume that Apple won't release many more kernel updates
> before these get fixed, which might help.
I'm fearful (perhaps unfairly so?) of providing kernel patches,
especially to file system-related issues.
-landonf