Hei all,
**
Before I start I'll apologize for the length. If you're interested
in the security and details of LittleSnitch read it all, the main
points are marked at the very end.
**
Most of you will remember the recent discussion, arond a month ago,
about requests for a command line interface to LittleSnitch. Several
users spoke out against this as a security hole. Additionally, the
official line from ObDev was that this has been a developer decision
that a command line tool is too much of a security hole.
Essentially, if a command line hook exists, malicious scripts and
programs can take advantage and exploit the hook.
My goal today is to express several points: the command line and
command line tools are not security holes, proper design of a command
line tool does not provide any additional risk, LittleSnitch is not
nearly as secure as past discussion seems to suggest.
Before I begin I'd just like to say that I love LittleSnitch. It
fills a valuable purpose and is very intuitive in configuration and
use. I'm not trying to stir up trouble. At the very least I want to
make LittleSnitch more useful and more secure. With that said I'll
get into it.
I'll start with the genesis of this message. A macosxhints.com [1]
hint recently suggested a method for temporarily allowing an
application to connect to the Internet while access to a GUI is not
possible [2]. Essentially, the hint used the GUI Scripting of
AppleScript to interact with the connection attempt window and
temporarily or permanently allow this or all connections. While this
hack fills the need for interaction without access to a GUI, it is
unabashedly a kludge that is not at all reliable. Among other things
I suspect that it would be possible for multiple windows to overlap
and result in a rule being accepted that was not desired.
In response to a comment of thanks I was contacted by the developer
of the script. He indicated that it was the recent exchange on the
LS mailing list that led to his development of the AppleScript and
that he wasn't entirely satisfied with the results. After some
further conversation and investigation we came to the first discovery
concerning security in LittleSnitch.
Instead of using AppleScript to allow one rule, the entire
LittleSnitch Daemon can be brought down with one command: killall
LittleSnitchDaemon
The reason for this is that the LittleSnitchDaemon, which interacts
with the installed kernel extension and monitors connections is run
in user space. The critical point here is that any malicious app
need not sneak rules into the LittleSnitch configuration or trick the
user into giving up control of LittleSnitch. Any malicious app that
is launched by the current user can simply kill the daemon process,
execute the required internet connections, and restart the
LittleSnitchDaemon. My testing has shown that this process results
in no indication to the user unless the LittleSnitch PrefPane is
currently active. In that case, the PrefPane will shrink and expand
as the daemon process is stopped and restarted.
The second security note is that if the Login Screen is active (ie.
no users logged in), the LittleSnitchDaemon is not running. Any
network requests at this stage will likewise not be intercepted.
The aforementioned AppleScript was then modified to include commands
for starting and stopping the LSDaemon process.
The point so far, regarding the script, is that where there is a need
users will either find a way to fill the need using a preferred
product, or find a new product. As far as I am aware the only
alternative to LittleSnitch is NetBarrier by Intego which also does
not include command line access. The snitchCTL script currently
fills the command line need, but it is far from perfect. Rules added
to the LS Configuration and temporary rules require a GUI Script to
be accepted, starting and stopping the daemon provides control but
opens a hole as any application is free to kill, exploit, restart the
daemon.
The proper solution is an integrated command line tool. The concerns
that a command line tool expose security holes are somewhat valid.
Implemented incorrectly the tool would allow a malicious app to alter
the LittleSnitch configuration to allow malicious behavior without
interrupting the daemon. This is clearly not the desired behavior,
however I'll use the example of ipfw as an example of why this would
not be the case. ipfw is the firewall suite used by MacOS X and many
other *nix based operating systems. Most users will know it simply
as the Sharing Preference Pane in System Preferences. It is a
straight forward GUI much like LittleSnitch. Create a new rule, add
ports and a definition, add rule. Behind the scenes these rules are
added to a configuration file as somewhat cryptic lines. Also much
like LS, the default is to deny all connections. And finally, you
never directly edit the ipfw configuration files. You use the
Sharing GUI or the ipfw command line tool to add, remove, or modify
rules.
ipfw is proven and does not suffer the security concerns expressed of
a LS command line tool. There are several key differences. You must
be a privileged user to configure ipfw behavior. Also, the ipfw
configuration files are owned by the root user [3]. The result here
is that in order to modify the firewall you have to be root. Granted
you can launch applications as root[4] which could take advantage of
this, but this scenario is moot for several reasons. The root user
is capable of anything. Root can delete any files, kill any process,
etc. The *nix environment is designed with privileges and abuse of
these privileges is at some point left as a fault of the user. This
is not to take an elitist view of users, but rather express the
design of *nix systems. MacOS X does something wonderful in
presenting an incredibly usable interface to an incredibly complex
operating system. At it's roots however, X is still *nix based and
relies on the same separation of privileges to control malicious
behavior.
What's the point of this example? LittleSnitch loses nothing by
adding a command line interface. In my mind this interface would
hold the following features:
list current LS rules
list LS status (access attempts that haven't been approved or denied)
remove rules
add rules
approve pending access attempts (with all the same options as the GUI
window)
In this way the command line tool would be very similar to the ipfw
command line tool, with the addition of pending and temporary rules.
ipfw is not a security concern because of user privilege separation.
The ipfw configuration files are owned by root but available for
modification through the GUI by privileged users through
authentication. Likewise LS configuration should be a root privilege
afforded to privileged users who authenticate in the GUI, as is
currently the case. Command line configuration would be achieved
only by the root user or through authentication methods such as sudo[5].
Finally, take a tip from BBEdit and only install the command line
tool if the user selects to install it. Throw up a dialogue to
indicate any concerns and instructions on use and then install if
confirmed. Also include a preference in the LS PrefPane to deny
command line configuration. This is then a GUI controllable action
and only failed by GUI scripting, but would still require
authentication. Users who don't understand, or don't accept, the
risks of command line configuration would be free to not install the
tool and not allow command line configuration. Users who understand
and accept the risks would be free to take those risks. As I've
said, any risks that are exposed by allowing a command line tool are
no more risky than an application gaining root privileges and taking
down LittleSnitch outright (something that currently doesn't even
require root access).
That's about it for me. Thanks for your time if you got this far.
If ANYONE is more curious about anything I've talked about here,
please feel free to contact me on or off list. As I said, I'm not
trying to tear down LS. This is about increasing its usefulness and
security.
The current version of the snitchCTL script is available at http://
snitchctl.smurfturf.net/
I do however, have some additional concerns regarding LittleSnitch
operation. These two points regard security and nitpicking :)
As mentioned the Daemon runs as a user process and is only running if
a user is currently logged in. A malicious application could fork a
background task that would not be quit on logout and wait for the
LoginScreen to be active before sending malicious data. A malicious
app could kill the daemon, execute a malicious connection, restart
the daemon without the user being aware. I propose that the daemon
should be a root process (or run as a separate user, as apache runs
as the www user) that is launched as part of the boot sequence. The
problem here is that different users may have different preferences
regarding LS blocking. This is up to the security concerns of the
machine owner but I can see two cases. LS has a separate root
configuration which is in effect when no users are logged in and is
augmented by user configurations or only one configuration is allowed
per machine and only root/privileged uses can modify the
configuration. I would be inclined to take the second option as
multiple configurations allow for security violations from one user
to be allowed by another user. There is after all only one firewall
configuration.
The LS configuration file contains a hash as a method of detecting
external editing. This hash is worthwhile, but not needed if the
configuration is owned by root under my proposed changes. In the
meantime the hash should be moved to a different file or included as
an entry in the configuration file. My reasoning here is that the
hash causes the configuration to fail XML validation. This is mostly
a nitpick, but it's irritating to see a purposely invalid XML file.
Moving the hash to another file would be simple. Moving the hash to
an entry in the file would require that the hash entry be ignored
when computing the hash.
[1] http://www.macosxhints.com/article.php?story=2005092816511024
[2] GUI access may not be possible for a number of reasons. Access
to AppleRemoteDesktop is not possible due to a lack of ARD client/
server or operating on a non-Mac Operating System (ssh using Putty in
Windows or ssh started under a *nix machine). ARD may also simply
not be an appropriate mechanism if a GUI is not desirable.
[3] Stored /Library/Preferences/com.apple.sharing.firewall.plist
under MacOS X.
[4] Using Psuedo for example.
[5] sudo authenticates the current user in the Terminal as root for a
limited amount of time
**
The Bottom Line
**
LittleSnitch is not currently secure.
"killall LittleSnitchDaemon" will allow any app to "phone home"
without being detected by LittleSnitch
Properly securing LittleSnitch would involve running the daemon and
all LittleSnitch components as the root user or as an independent
LittleSnitch user.
This separation is inline with the intended architecture of unix
platforms (MacOS X included) and lends itself quite well to a command
line interface.
If a properly implemented command line interface is considered to be
a security hazard then the entire structure of the operating system
is a security hazard.
The main point to take away from this is that as it is currently
implemented, LittleSnitch is not secure.
A malicious app need not sneak new rules in to the configuration when
the communication block is not effective.
**
The most important request here is to secure LittleSnitch.
**
Thanks for you time.
-- --
arno s. hautala /-\ [EMAIL PROTECTED]
-- --
_______________________________________________
Littlesnitch-talk mailing list
Littlesnitch-talk@obdev.at
http://at.obdev.at/mailman/listinfo/littlesnitch-talk
