|
|||||||
![]() |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
#1 | |||||||||||||||||||
|
Prospect
Join Date: Dec 2002
Location: Montréal
Posts: 44
|
I previously posted a hint about using AppleScript UI Scripting to allow LittleSnitch while logged via SSH, this is a follow up on the story.
I decided it was not enough and came up with a php shell script to manage the LittleSnitch daemon via the terminal. This is how SnitchCTL was born. It allows to start, stop and restart the daemon as well as use the UI Script to allow or deny a connection. It also allows to add basic allow/deny al rules to the configuration. The script is available here. I have also set up a page for the script. The source is available from the site. While creating this script I discovered that LittleSnitch was really not as secured as it should/appears to be. Fracai has posted a great warning call on the LittleSnitch mailinglist. Here's a snippet:
The mailinglist post is available here. Yes you've read that properly. The LittleSnitch daemon runs in user space! This means any malicious application can stop the daemon, sent the data and then start the daemon back up with very little change that the user ever knows about it! LittleSnitch doesn't output to the system/console log so there is no logs of what's been going on. I suggest you read the site I've put up and the mailing list post by Fracai if you want to know more about this issue. |
|||||||||||||||||||
|
|
|
|
|
#2 | |||||||||||||||||||
|
Prospect
Join Date: Dec 2002
Location: Montréal
Posts: 44
|
*** The security hole in LittleSnitch is not pure speculation. A malware already has taken advantage of it! ***
I was looking to see what the web had to say about LittleSnitch's security (googling with the terms "LittleSnitch Security") and something very interesting came up from Symantec's opener description page (http://securityresponse.symantec.com....renepo.b.html)
So I decided to search around a bit more to see what I could find. These are my findings. They are not exactly structured, but a lot of information can be found on these sites. This information is well documented on many sites such as:
*** Objective Development has been aware of this for over a year but seamed to have decided not to act! *** http://www.mail-archive.com/littlesn.../msg00132.html (Note that they never mention in the mailinglist post that the malware kills the LittleSnitch daemon!) The malware was featured on:
More information about the SH.Renepo.B malware :
You can view this post here Last edited by xSmurf; 10-05-2005 at 07:09 PM. Reason: Correcting improperly used terms (virus -> malware) |
|||||||||||||||||||
|
|
|
|
|
#3 | |||||||||||||||||||||||
|
Site Admin
Join Date: Jan 2002
Location: Montreal
Posts: 32,473
|
Except that "opener" is not a virus. It is merely a root kit. I.e. it is a set of utilities designed to cover your tracks after you have broken into an OS X machine and gained administrator access. It does not propagate on its own. The use of the word "virus" in connection with this is therefore incorrect. |
|||||||||||||||||||||||
|
|
|
|
|
#4 |
|
League Commissioner
Join Date: Jan 2005
Posts: 8,475
|
I could be wrong, so correct me if I am, but as far as I know, the Renepo virus was never released in the wild, and soon after it was "announced" in 2004 there was a software update that closed the vulnerability. If that is true, then Little Snitch needs no further protection.
|
|
|
|
|
|
#5 |
|
Prospect
Join Date: Dec 2002
Location: Montréal
Posts: 44
|
Hayne: you are totaly right about this. I guess I used the term virus as it's understood by the general public. Be sure that I fully understand the difference.
CWT: Even if the vulnerability to Renepo has been fixed, the fact remains: LittleSnitch runs in user space. Thus any malicious application launched by the user can bring down the daemon and open the network. My point by bringing up Renepo was not to bring a specific case, but more to prove that the threat is real, may it be from an opener, spyware or simply by a shameless developer who wants his application to "phone home". |
|
|
|
|
|
#6 |
|
MVP
Join Date: May 2004
Posts: 2,100
|
Every reference to a LittleSnitch vulnerability regarding Opener has been that Opener kills LittleSnitch. I assume this to mean killing the daemon as the daemon is required for connections to be blocked. The LS mailing list response indicates that LS simply ignores the kill request. While this may be true (many of the kill signals are ignorable) it is not foolproof. SIGKILL is nonignorable. Also, the LSDaemon, as mentioned, runs in user space and can therefore be killed by the current user. I can't imagine what inspired the developers to state that LS ignores kill commands even from the super-user. I'd like to see any part of LS defy "sudo kill -9". Heck, from my testing the daemon, which if killed brings down the filtering of LS, can be brought down by a simple kill command.
The bottom line is that any app that wants unrestricted network access can simply kill the LSDaemon (and then bring it back up if the app wants to be extra sneaky). Opener is an example of this, regardless of whether it's in the wild. Plus, you're not going to see an app advertise that it interfers with LittleSnitch and I think it'd be pretty difficult to detect in practice. |
|
|
|
|
|
#7 | |||||||||||||||||||||||
|
Prospect
Join Date: Dec 2002
Location: Montréal
Posts: 44
|
I'd like to add, as I mentioned earlier, that Little Snitch does not output anything to the console or system logs. This makes it pretty hard to try and track down malicious activity. Maybe having a separate log file would be a good idea, the kext could also monitor the daemons activity for greater security. Afterall, ipfw, apache, in fact pretty much any system thread or daemon I can think logs activity in a way or another. Heck, even my DNS Update (ddclient) daemon does! ** Ten minutes later ** As a matter of fact I just added Console logging to SnitchCTL. Build 007 is avalaible on the site Last edited by xSmurf; 10-05-2005 at 08:35 PM. |
|||||||||||||||||||||||
|
|
|
|
|
#8 |
|
League Commissioner
Join Date: Sep 2003
Location: Old Europe
Posts: 5,146
|
To further clear things up:
Opener is a shell script (!) that accumulates a couple of neat tricks (you can get it if you check out the right URL already posted here). Last time I looked, it was nowhere near being a rootkit (there are OS X rootkits) and like hayne correctly pointed out, it has no propagation part. The big fuss started when some "security firm" of questionable quality started a big PR campaign using it and things got completely out of proportion then. xSmurf, you might want to invite the author of LS to this thread to discuss his security concepts here. It would probably need to be rewritten as a kext lacking an unload call to be entirely bulletproof. |
|
|
|
|
|
#9 |
|
MVP
Join Date: May 2004
Posts: 2,100
|
based on the mailing list responses so far from ObDev (nil) I don't think a discussion is of any interest at this point
also, as far as I'm aware, KEXTs have to have an unload call. I suppose it wouldn't have to do anything, but that would probably just bring down the system. actually, in practice this might be what LS is doing (xSmurf has experienced this while unloading the KEXT). and, to be "bulletproof" is essentially impossible. the best you can hope for is that interfering with the filtering is limited to root and authenticated users. beyond that it's up to the security practices of the user. that's why Opener IS a good example here. yes, Opener is useless unless the user runs it. don't put it past the users to do this. remember the 200kB Office install that came out a few years ago? also, Opener is useless because it runs as root. the LS vulnerability is exploitable in user-space. any app could exploit LS without any authentication from the user. the KEXT is fine as it stands. you have to use sudo to unload KEXTs. at the least, the LSDaemon needs to run as root in order to remove arbitrary control from user-space. you already have to authenticate to use the PrefPane. I'm not sure why you don't have to authenticate to add rules as apps attempt access. I'd appreciate discussion with the devs as well, but security responses like this don't seem to hold much weight. I'd love to be proven wrong here, I'm basing this solely on their responses to this issue, the Opener response, and the original request for a command line interface. |
|
|
|
|
|
#10 |
|
MVP
Join Date: May 2004
Posts: 2,100
|
and I've been proven wrong, for the time being. the ObDev response states that the main developer is on vacation and will of course respond when back.
|
|
|
|
|
|
#11 |
|
League Commissioner
Join Date: Sep 2003
Location: Old Europe
Posts: 5,146
|
There are already kexts with unload calls that either do nothing or panic the machine, which wouldn't leave room for nefarious network manipulations but be a kind of DoS.
Overall, Apple has gotten extremely lucky so far with various, sometimes very stupid errors, especially in the closed-source part, stuff like the Safari mounts disk-images automagically, then executes arbitrary code with HelpViewer URLs. Ugly. Shouldn't happen. |
|
|
|
|
|
#12 |
|
MVP
Join Date: May 2004
Posts: 2,100
|
Those KEXTs are poor coding. Apple can't do too much to force them to work properly. Only encourage the good behavior. I'd also be interested to see what happens with a KEXT that doesn't want to unload. I'd suspect it simply causes a crash. Based on my research of KEXTs the unload methods (really just a stop method) the only function is to clean up. A KEXT that doesn't do this is poorly coded and would most likely crash.
As for the stupid errors... The Safari stuff is borderline. On its own, there's no problem. It's the combination with the HelpViewer URI that caused the problems. And Apple closed the hole. They also added the "do you trust this application" dialog when launching new apps. Lucky in the sense that they responded to a problem. You're right it shouldn't happen, but Apple is far from the worst offender and when a problem is found they fix it. Finally, the worst exploits I've ever seen have been apps that could delete the home folder. Devestating to the user, but nowhere near the problems of Windows zombie computers. I guess I'm not quite sure what you mean by Apple being lucky. Regardless, software that is intended to be an aid to the user shouldn't try to trick the system with things like unloadable KEXTs or unkillable daemons. That's a malicious app in my mind. |
|
|
|
|
|
#13 |
|
Prospect
Join Date: Dec 2002
Location: Montréal
Posts: 44
|
I decided to pull a quick build before night. Build 8 added an option to crash the remote machine by unloading LittleSnitch's kext. I haven't tested it a lot. You probably understand why
I'm also unsure if it will crash every time or not, but I'm sure it will crash even with very few apps running. Anyway, if you find something wrong with it let me know.
|
|
|
|
|
|
#14 | |||||||||||||||||||||||
|
League Commissioner
Join Date: Sep 2003
Location: Old Europe
Posts: 5,146
|
What I mean is stuff like what you can read in this over 10 months old paper: http://21c3.annulator.de/OSXInsecurity.pdf And having grossly incompetent competitors does not excuse lacking quality of your own product, especially if you promote the security aspect of it without being serious about it. |
|||||||||||||||||||||||
|
|
|
|
|
#15 |
|
Prospect
Join Date: Dec 2002
Location: Montréal
Posts: 44
|
Thinking about all this I have realized that the answer given last year concerning the Opener might not be as bogus as I thought. I have tried SnitchCTL under 10.3 and indeed the daemon cannot be killed (at least not with the few commands I've tried - kill, kill -9, killall). But there's a glitch, first I don't find this behaviour normal, imho anything should be killable by root; what if it's making a conflict with another app. Second thing is that it is easily defeated as unlike in 10.4, you can kill the kext (extension) which in turn will kill the daemon. To make it worst, you can't start it back after you've unloaded the kext, a restart is required. Indeed, loading the LittleSnitch.kext located in the Contents of the prefpane will say it's missing dependencies, try and load the ODKUControl.kext and it will result in a panel saying the app is not authentic and that is cannot be loaded.
Last edited by xSmurf; 10-07-2005 at 05:25 PM. |
|
|
|
|
|
#16 |
|
Registered User
Join Date: Oct 2005
Posts: 1
|
I don't have the experience to make this myself, but would anyone be interested in an open-source alternative to LittleSnitch? I think it would be great since there ought to be a free version of such a nice concept, one that doesn't phone home itself..
|
|
|
|
|
|
#17 |
|
Prospect
Join Date: Dec 2002
Location: Montréal
Posts: 44
|
After building the proof of concept that SnitchCTL is I thought I should help the users who are scared because of the issues it brings up. This is why I came up with VeriSnitch: http://snitchctl.smurfturf.net/index/verisnitch/
VeriSnitch is a daemon that will monitor LittleSnitch and warns the user, via the GUI, if it is not running as well as log to the console. It is a combination of a command tool and a launchd plist to make it run at 30 seconds interval. Yes it is possible that and app could bring down the daemon and phone home in less than 30 seconds. But I think this adds a fairly good level of security. It comes in a user-friendly installer package so you don't have to be "terminally literate" to use it. It is somewhat untested so if you come across bugs be sure to let me know, but I believe it should work just fine for most users. Feedback is always appreciated, so be sure to let me know what you think. |
|
|
|
|
|
#18 |
|
League Commissioner
Join Date: Sep 2003
Location: Old Europe
Posts: 5,146
|
You just re-invented a concept that is at least 35 years old:
"Here is a story about one of the classic computer hacks: Back in the mid-1970s, several of the system support staff at Motorola discovered a relatively simple way to crack system security on the Xerox CP-V timesharing system. Through a simple programming strategy, it was possible for a user program to trick the system into running a portion of the program in ‘master mode’ (supervisor state), in which memory protection does not apply. The program could then poke a large value into its ‘privilege level’ byte (normally write-protected) and could then proceed to bypass all levels of security within the file-management system, patch the system monitor, and do numerous other interesting things. In short, the barn door was wide open. Motorola quite properly reported this problem to Xerox via an official ‘level 1 SIDR’ (a bug report with an intended urgency of ‘needs to be fixed yesterday’). Because the text of each SIDR was entered into a database that could be viewed by quite a number of people, Motorola followed the approved procedure: they simply reported the problem as ‘Security SIDR’, and attached all of the necessary documentation, ways-to-reproduce, etc. The CP-V people at Xerox sat on their thumbs; they either didn't realize the severity of the problem, or didn't assign the necessary operating-system-staff resources to develop and distribute an official patch. Months passed. The Motorola guys pestered their Xerox field-support rep, to no avail. Finally they decided to take direct action, to demonstrate to Xerox management just how easily the system could be cracked and just how thoroughly the security safeguards could be subverted. They dug around in the operating-system listings and devised a thoroughly devilish set of patches. These patches were then incorporated into a pair of programs called ‘Robin Hood’ and ‘Friar Tuck’. Robin Hood and Friar Tuck were designed to run as ‘ghost jobs’ (daemons, in Unix terminology); they would use the existing loophole to subvert system security, install the necessary patches, and then keep an eye on one another's statuses in order to keep the system operator (in effect, the superuser) from aborting them. One fine day, the system operator on the main CP-V software development system in El Segundo was surprised by a number of unusual phenomena. These included the following: Tape drives would rewind and dismount their tapes in the middle of a job. Disk drives would seek back and forth so rapidly that they would attempt to walk across the floor (see walking drives). The card-punch output device would occasionally start up of itself and punch a ‘lace card’ (card with all positions punched). These would usually jam in the punch. The console would print snide and insulting messages from Robin Hood to Friar Tuck, or vice versa. The Xerox card reader had two output stackers; it could be instructed to stack into A, stack into B, or stack into A (unless a card was unreadable, in which case the bad card was placed into stacker B). One of the patches installed by the ghosts added some code to the card-reader driver... after reading a card, it would flip over to the opposite stacker. As a result, card decks would divide themselves in half when they were read, leaving the operator to recollate them manually. Naturally, the operator called in the operating-system developers. They found the bandit ghost jobs running, and killed them... and were once again surprised. When Robin Hood was gunned, the following sequence of events took place: !X id1 id1: Friar Tuck... I am under attack! Pray save me! id1: Off (aborted) id2: Fear not, friend Robin! I shall rout the Sheriff of Nottingham's men! id1: Thank you, my good fellow! Each ghost-job would detect the fact that the other had been killed, and would start a new copy of the recently slain program within a few milliseconds. The only way to kill both ghosts was to kill them simultaneously (very difficult) or to deliberately crash the system. Finally, the system programmers did the latter — only to find that the bandits appeared once again when the system rebooted! It turned out that these two programs had patched the boot-time OS image (the kernel file, in Unix terms) and had added themselves to the list of programs that were to be started at boot time (this is similar to the way Windows viruses propagate). The Robin Hood and Friar Tuck ghosts were finally eradicated when the system staff rebooted the system from a clean boot-tape and reinstalled the monitor. Not long thereafter, Xerox released a patch for this problem. It is alleged that Xerox filed a complaint with Motorola's management about the merry-prankster actions of the two employees in question. It is not recorded that any serious disciplinary action was taken against either of them." quoted from: http://catb.org/~esr/jargon/html/meaning-of-hack.html Hopefully, the authors of little snitch will get their act together before you figure out a way how to punch lace-cards .
|
|
|
|
|
|
#19 |
|
Prospect
Join Date: Dec 2002
Location: Montréal
Posts: 44
|
Well I thank you for this, maybe this way more people will understand the meaning of 'hack' after this and also realize that it's the way to do things when people refuse to see the truth. Anyhow, VeriSnitch seams to be fairly popular. It's not the best solution, but it does what's it's intended to do. I have been called a wonk when I came out with the initial script, yet I provide a fix and no one seams to want to comment. I find it pretty funny.
Last edited by xSmurf; 10-10-2005 at 07:01 PM. |
|
|
|
|
|
#20 |
|
Prospect
Join Date: Dec 2002
Location: Montréal
Posts: 44
|
VeriSnitch was updated...
Completely runs as root, LS Daemon included, also added verification of the dismissal and a better work flow. It will also not run if there are no users logged in, but it'll wait for one in background. I also corrected numberous bugs. It is probably a good thing to use DesInstaller to delete any previous install. This is based on a plist idea that came from the LS mailinglist. This shows the warning alert (dismisses after 5 seconds). ![]() This shows the dismissal alert (random number). ![]() See the page for more info this is not exactly secure as it can be byspassed by UI Scripting If anyone knows how to use os x authentication gui from apple script, please let me know! Now launches the LS Daemon in root! Last edited by xSmurf; 10-13-2005 at 12:13 AM. |
|
|
|
![]() |
|
|