Mac OS X stores login/Keychain/FileVault passwords on disk

[Matt Johnston]

It seems that Mac OS X (10.3.4 tested) doesn't bother clearing memory
containing sensitive data, or using mlock() to avoid swapping.

A quick grep of the swapfiles will show up various morsels:

rez:~> sudo strings -8 /var/vm/swapfile0 |grep -A 4 -i longname
longname
password
<user's password here>
/bin/zsh
username
---
.... various other occurrences follow


Grepping for context around "password" also shows up results, and grepping
for portions of a Keychain password (differing from the login password)
will also get results. It appears that loginwindow is one of the apps involved,
I haven't investigated what else is involved. The amount of memory and usage
patterns of the machine will affect what gets swapped, though loginwindow seems
likely to get swapped early since it is seldom used after login.

Obviously this is only of interest if an attacker has root (or physical)
access to a machine, however it does make FileVault or Keychain encryption
fairly useless. It appears that the swapfiles are removed on shutdown or
startup, though not wiped - pulling the power from a sleeping machine, and/or
booting from CD, would quite easily retrieve the password(s).

Reported to Apple on 21 June, I haven't had any response. It'd be nice if
they at least said "we're taking a look if it's an issue".

Matt

[Adi Kriegisch]

The swapfiles are deleted on startup -- this means even a clean shutdown by
user leaves the passwords on disk.
So if you loose your powerbook someone might boot it in "target disk mode" and
will be able to get your password!

Adi

===
> It seems that Mac OS X (10.3.4 tested) doesn't bother clearing memory
> containing sensitive data, or using mlock() to avoid swapping.
>
> A quick grep of the swapfiles will show up various morsels:
>
> rez:~> sudo strings -8 /var/vm/swapfile0 |grep -A 4 -i longname
> longname
> password
> <user's password here>
> /bin/zsh
> username
> ---
> ... various other occurrences follow
>
>
> Grepping for context around "password" also shows up results, and grepping
> for portions of a Keychain password (differing from the login password)
> will also get results. It appears that loginwindow is one of the apps
> involved, I haven't investigated what else is involved. The amount of
> memory and usage patterns of the machine will affect what gets swapped,
> though loginwindow seems likely to get swapped early since it is seldom
> used after login.
>
> Obviously this is only of interest if an attacker has root (or physical)
> access to a machine, however it does make FileVault or Keychain encryption
> fairly useless. It appears that the swapfiles are removed on shutdown or
> startup, though not wiped - pulling the power from a sleeping machine,
> and/or booting from CD, would quite easily retrieve the password(s).
>
> Reported to Apple on 21 June, I haven't had any response. It'd be nice if
> they at least said "we're taking a look if it's an issue".
>
> Matt

[Theo Van Dinter]

--AZ3TfZx6WW1DY2Jl
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 12, 2004 at 11:05:45AM +0200, Adi Kriegisch wrote:
> So if you loose your powerbook someone might boot it in "target disk mode=
" and=20
> will be able to get your password!

FWIW: You can enable the security features of OpenFirmware on modern Apple
hardware, such that things like "boot from CD", "target disk mode", etc,
are all disabled.

It adds at least another barrier for people to have to get around to
get your data. More information is available via a Google search,
but the following URL is a pretty good reference:

http://www.mactipsandtricks.com/tips/display.lasso?mactip=3D118

--=20
Randomly Generated Tagline:
I'm a white male, aged 18 to 49. Everyone listens to me! No matter
how dumb my suggestions are.
=20
-- Homer Simpson
Lisa vs. Malibu Stacy

--AZ3TfZx6WW1DY2Jl
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA9uKh7tgKAJaXVyoRArtiAJ458tV3qo+7bvSELiyK0E TbMAgKXACcC4t2
2hr0h2tJaVLf47Tt/l2VJtU=
=5DSU
-----END PGP SIGNATURE-----

--AZ3TfZx6WW1DY2Jl--

[Ray Slakinski]

This all depends on the amount of ram you have and what is nornally
done on your mac. Still a major issue you have, but if you put in
>640 you probably have nothing to worry about. A sad work around I
know, but while we wait for the ever slow to fix things - namely Apple
- its the best you can do.

[-----]
Ray Slakinski

GnuPG Fingerprint:
9065 5C54 2C4A B13B 52BB C37A 125B F012 08A7 0A54

Blog: http://ddll.sdf1.net

On Mon, 12 Jul 2004 11:05:45 +0200, Adi Kriegisch <adi@cg.tuwien.ac.at> wrote:
> The swapfiles are deleted on startup -- this means even a clean shutdown by
> user leaves the passwords on disk.
> So if you loose your powerbook someone might boot it in "target disk mode" and
> will be able to get your password!
>
> Adi

The issue of getting into AES128 encrypted disk images is easy to
unravel with this swapfile problem.

We'll start by grabbing the volume name of an AES128 encrypted disk
image file. Assuming the image name is test1.dmg, try:

root# strings -8 /var/vm/swapfile* | grep -B1 test1.dmg | grep
Volumes
/Volumes/SECRET

Armed with the volume name, we can grab the file listing of that
(supposedly protected) AES128 encrypted disk image. Since our
volume name is 'SECRET'. Try:

root# strings -8 /var/vm/swapfile* | grep "<string>/Volumes/SECRET"
<string>/Volumes/SECRET/secretporn.pdf</string>
<string>/Volumes/SECRET/secretphoto.jpg</string>
<string>/Volumes/SECRET/badmovie.mpg</string>
<string>/Volumes/SECRET/horriblybadmovie.mpg</string>
<string>/Volumes/SECRET/naughty.mpg</string>
<string>/Volumes/SECRET</string>

To REALLY get at those (supposedly protected) files, we could use the
password. It's easy to grab it even if it's not in the keychain:

root# strings -8 /var/vm/swapfile* | grep -B1 "/System/Library/
CoreServices/DiskImageMounter.app"

[... snip ... ]
--
mySecretPasswordTest
/System/Library/CoreServices/DiskImageMounter.app
[... snip ... ]

The only chore may be figuring out which password goes with which
disk image. And that's not nearly the chore of popping AES128
encryption...

j0hnny

http://johnny.ihackstuff.com
johnny@ihackstuff.com



-------------------------------------
From: Adi Kriegisch <adi@cg.tuwien.ac.at>
To: bugtraq@securityfocus.com
Subject: Re: Mac OS X stores login/Keychain/FileVault passwords on
disk
Sent: Monday, July 12, 2004 9:05 AM



The swapfiles are deleted on startup -- this means even a clean
shutdown by
user leaves the passwords on disk.
So if you loose your powerbook someone might boot it in "target disk
mode" and
will be able to get your password!

Adi

===




It seems that Mac OS X (10.3.4 tested) doesn't bother clearing memory
containing sensitive data, or using mlock() to avoid swapping.

A quick grep of the swapfiles will show up various morsels:

rez:~> sudo strings -8 /var/vm/swapfile0 |grep -A 4 -i longname
longname
password
<user's password here>
/bin/zsh
username
---
.... various other occurrences follow


Grepping for context around "password" also shows up results, and
grepping
for portions of a Keychain password (differing from the login password)
will also get results. It appears that loginwindow is one of the apps
involved, I haven't investigated what else is involved. The amount of
memory and usage patterns of the machine will affect what gets
swapped,
though loginwindow seems likely to get swapped early since it is
seldom
used after login.

Obviously this is only of interest if an attacker has root (or physical)
access to a machine, however it does make FileVault or Keychain
encryption
fairly useless. It appears that the swapfiles are removed on shutdown
or
startup, though not wiped - pulling the power from a sleeping
machine,
and/or booting from CD, would quite easily retrieve the password(s).

Reported to Apple on 21 June, I haven't had any response. It'd be nice
if
they at least said "we're taking a look if it's an issue".

Matt

[Kurt Seifried]

>FWIW: You can enable the security features of OpenFirmware on modern Apple
>hardware, such that things like "boot from CD", "target disk mode", etc,
>are all disabled.

FWIW this is utterly worthless.

>It adds at least another barrier for people to have to get around to
>get your data. More information is available via a Google search,
>but the following URL is a pretty good reference:
>
>http://www.mactipsandtricks.com/tips/display.lasso?mactip=3D118

To quote myself:

http://www.seifried.org/lasg/system/index.html

Unfortunately if you are using Apple hardware you cannot secure the boot
process in any meaningful manner. While booting if the user holds down the
command-option-P-R keys it will wipe any settings that exist, there is no
way to avoid this. About the only security related option you can set is
whether the machine automatically reboots or not, this is useful for servers
to prevent a remote attacker from changing the kernel for example (which
require a system reboot). Hold down the command-option-O-F keys to access
the OpenFirmware and from there you need to:
go> setenv auto-boot? FalseHowever because a local attacker can easily flush
the settings there is no inherent security. If you need to use Apple systems
as servers then it is highly advisable to lock them in a cabinet of some
sort. As workstations in a public area your best solution is to automate the
reloading of the OS to speed recovery time.

Kurt Seifried, kurt@seifried.org
A15B BEE5 B391 B9AD B0EF
AEB0 AD63 0B4E AD56 E574
http://seifried.org/security/

[James Goodlet]

On 17/7/04 5:17 am -0700, Kurt Seifried wrote:

> To quote myself:
>
> http://www.seifried.org/lasg/system/index.html
>
> Unfortunately if you are using Apple hardware you cannot secure the boot
> process in any meaningful manner. While booting if the user holds down the
> command-option-P-R keys it will wipe any settings that exist, there is no
> way to avoid this.

Err, have you actually tried that? See

<http://docs.info.apple.com/article.html?artnum=106482>

and note the section which states that one of the effects of turning on
"Open Firmware Password Protection" is that it "Blocks a reset of Parameter
RAM (PRAM) by pressing the Command-Option-P-R key combination during
startup". This has certainly been my experience here.

Your point on physical security though is well made, and it is trivial to
defeat most BIOS controls if you have physical access to the device.

James
--
James Goodlet, Head of Infrastructure Services,
IT Services, University of Sussex, Brighton BN1 9QJ
GPG: E214 6C8F 785F 95CC 33E3 A72E A6FE D13D 055A B934

[Chris Boyd]

On Sat, 2004-07-17 at 07:17, Kurt Seifried wrote:

> If you need to use Apple systems
> as servers then it is highly advisable to lock them in a cabinet of
> some
> sort.

Current Xserves come with a small key that you can use to lock in drives
and lock out local keyboards and mice.

http://www.apple.com/xserve/management.html

[Michael Shirk]

Pretty much it is a security risk to have an Apple laptop or desktop process
any classified information. As long as physical access is used as you
suggested a lock rack you are fine for 1U Xserves. However, the typical user
on a subway with an iBook could be a major risk.

I have set all of the options possible as well as the security setting in
OpenFirmware:

setenv security-mode full

But I need to get a laptop back with a key lock and a cinder block so no one
can take it. However, mac laptops are really just attack boxes and not meant
to be secure.

:-)

shirkdog
http://www.shirkdog.us

-----Original Message-----
From: bt@seifried.org [mailto:bt@seifried.org]
Sent: Saturday, July 17, 2004 8:17 AM
To: bugtraq@securityfocus.com
Subject: Re: Mac OS X stores login/Keychain/FileVault passwords on disk
Importance: Low


>FWIW: You can enable the security features of OpenFirmware on modern Apple
>hardware, such that things like "boot from CD", "target disk mode", etc,
>are all disabled.

FWIW this is utterly worthless.

>It adds at least another barrier for people to have to get around to
>get your data. More information is available via a Google search,
>but the following URL is a pretty good reference:
>
>http://www.mactipsandtricks.com/tips/display.lasso?mactip=3D118

To quote myself:

http://www.seifried.org/lasg/system/index.html

Unfortunately if you are using Apple hardware you cannot secure the boot
process in any meaningful manner. While booting if the user holds down the
command-option-P-R keys it will wipe any settings that exist, there is no
way to avoid this. About the only security related option you can set is
whether the machine automatically reboots or not, this is useful for servers
to prevent a remote attacker from changing the kernel for example (which
require a system reboot). Hold down the command-option-O-F keys to access
the OpenFirmware and from there you need to:
go> setenv auto-boot? FalseHowever because a local attacker can easily flush
the settings there is no inherent security. If you need to use Apple systems
as servers then it is highly advisable to lock them in a cabinet of some
sort. As workstations in a public area your best solution is to automate the
reloading of the OS to speed recovery time.

Kurt Seifried, kurt@seifried.org
A15B BEE5 B391 B9AD B0EF
AEB0 AD63 0B4E AD56 E574
http://seifried.org/security/

__________________________________________________ _______________
Don’t just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

[Adi Kriegisch]

17.07.2004 23:00

There is one thing about this which makes more than just "lost notebook" or
"accessible data" out of this:
If you have the login password you have access to the "login keychain" -- the
keychain which is unlocked with the users pasword at login time.

[ For those who have no idea what keychain is:
(taken from http://www.apple.com/macosx/features/security/)
"A Secure Keychain
To make it easy to manage the daunting number of passwords and permissions
intrinsic to network computing, Mac OS X includes a Keychain. The Keychain
stores all your information to log onto file servers, ftp servers and Web
servers and to use encrypted disk images." (and so on)
]

You might create different keychains as well but the problem is your login
keychain contains -- at least for most users -- all your webform data,
passwords (online banking, ...), access credentials for file servers, your
encrypted disk images' passwords and even vpn-passwords if any is used for
accessing some private net.

I would not mind if anyone could get just some data; even enabling firmware
protection is of _NO_ use: just take the hard disk out of the
computer/notebook.
The problem here is that it is easy to get information which seems to be
protected within an encrypted file -- or as apple puts it: "a secure
keychain".

What I suggest as a temporary solution is to put no information into your
login keychain, create another keychain with different password and remove
all vital information from your login keychain. (please comment on this --
I'm not sure if I didn't forget anything)

Deleting or overwriting swapfiles is no feasible way because one can never be
sure if the password still is on disk somewhere. "Secure deleting" would only
be possible with overwriting a complete swap partition; MacOSX is dynamically
allocating disk space for swapping. So even if this bug is fixed you cannot be
sure that your password is not on disk any more after updating. Only solution
to this might be to completely fill the free space on root partition and
whipe it then... -- check with a grep for your password over the whole
partition to be really sure, or (simpler) choose a different password ;-)

Adding more ram is no solution to this problem as well because the login
application is started very early and then not used for quite some time and
MacOSX starts swapping it long before the end of ram is reached... (these are
at least my experiences)

ad apple: pls fix asap... btw: this was reported on June 21st by Matt Johnston
first and is a critical bug!

Adi