Unpatched macOS vulnerability lets remote attackers execute code

Internet shortcuts come with code execution capability. Latest Mac not fully patched.

Read the whole story

 

[Norphy]

OK, I get that security is hard. I get that there are millions of lines of code in an operating system and things like this are going to fall through the cracks. Honestly, I do.

However, is it just me or is Apple getting particularly bad for this just recently? This. The recent iOS text message bug. The thing where you could get root without a password. Reading that Facebook post where it mentioned Microsoft going back to basics for security in the early 00s, I'm wondering if Apple need to do the same; dial back a bit on yearly OS releases and focus on security?

 

[Deleted member 161099]

The "just fix it with a regexp for '^file:'" solution really does smell of getting the most junior intern in the place to just do something to get rid of it... No engineer with a focus on or clue about security would do that.

The nature of the fix says something about how focused on security Apple is, and is far more worrying than the original vulnerability.

 

[Deleted member 823177]

This snippet with just eight lines of code is what launched the Calculator shown above. But any skillful threat actor could modify this test code to execute outright malicious code on the victim's machine.

how, though? does the file: URI handler accept arguments in the command, or is there another way to provide the malicious payload? a drive-by download might work, but since macOS is Unix, wouldn't it require the execute permission bit be set on the file somehow?

(obviously, this is a serious security issue - i'm just curious specifically how an attack would work.)

 

[AmorImpermissus]

While the threat landscape for MacOS is, over all, considerably lower than for Windows systems, I'm grateful to Ars for articles like this. You'd be amazed how many of my Mac users still regularly complain that we require security software because "Macs don't get viruses." Being able to quickly link management to mainstream IT publications like this means they believe me when I call bullshit.
(Edited for clarity)

 

[Voo42]

I understand that security is hard and all, but come on. Doing a case sensitive comparison is such an obvious error that I can't imagine this was carefully reviewed.

 

[torp]

This snippet with just eight lines of code is what launched the Calculator shown above. But any skillful threat actor could modify this test code to execute outright malicious code on the victim's machine.

how, though? does the file: URI handler accept arguments in the command, or is there another way to provide the malicious payload? a drive-by download might work, but since macOS is Unix, wouldn't it require the execute permission bit be set on the file somehow?

(obviously, this is a serious security issue - i'm just curious specifically how an attack would work.)

Exactly. While you can run arbitrary files on the user's machine from an email like this, those files have to already exist on the target machine. How do you exploit it on a standard Mac OS installation?

 

[Sajuuk]

OK, I get that security is hard. I get that there are millions of lines of code in an operating system and things like this are going to fall through the cracks. Honestly, I do.

However, is it just me or is Apple getting particularly bad for this just recently? This. The recent iOS text message bug. The thing where you could get root without a password. Reading that Facebook post where it mentioned Microsoft going back to basics for security in the early 00s, I'm wondering if Apple need to do the same; dial back a bit on yearly OS releases and focus on security?

It's funny because I feel like I've been seeing this exact sentiment here, nearly word-for-word, for the last ~5 years?

 

[Derecho Imminent]

The original flaw is bad enough, but even worse that their fix can be bypassed by simply changing the caps. wth?? Did they put an intern on the job?

 

[Mr.Morden]

OK, I get that security is hard. I get that there are millions of lines of code in an operating system and things like this are going to fall through the cracks. Honestly, I do.

However, is it just me or is Apple getting particularly bad for this just recently? This. The recent iOS text message bug. The thing where you could get root without a password. Reading that Facebook post where it mentioned Microsoft going back to basics for security in the early 00s, I'm wondering if Apple need to do the same; dial back a bit on yearly OS releases and focus on security?

Or has Apple always been just as bad as everyone else, but now that malware is commercializing it's starting to come to light.

 

[Derecho Imminent]

This snippet with just eight lines of code is what launched the Calculator shown above. But any skillful threat actor could modify this test code to execute outright malicious code on the victim's machine.

how, though? does the file: URI handler accept arguments in the command, or is there another way to provide the malicious payload? a drive-by download might work, but since macOS is Unix, wouldn't it require the execute permission bit be set on the file somehow?

(obviously, this is a serious security issue - i'm just curious specifically how an attack would work.)

Exactly. While you can run arbitrary files on the user's machine from an email like this, those files have to already exist on the target machine. How do you exploit it on a standard Mac OS installation?

Might it be possible to run a couple genuine mac programs which would download the malware then run it?

 

[deet]

I came expecting a flaw that allowed an attacker to run untrusted binary code. While this can clearly be used to try to convince a user to open something unusual, the code in question must already exist on the device, no? And opening something unsigned or untrusted would trigger gatekeeper warnings, no?

I mean, this is a dumb attempt at a fix, but I am missing how this is worse than any other means of opening an executable file.

 

[jingo]

I came expecting a flaw that allowed an attacker to run untrusted binary code. While this can clearly be used to try to convince a user to open something unusual, the code in question must already exist on the device, no? And opening something unsigned or untrusted would trigger gatekeeper warnings, no?

I mean, this is a dumb attempt at a fix, but I am missing how this is worse than any other means of opening an executable file.

Personally I think the article needs to be modified to address these points, which occurred to me instantly I read about the issue. The article speaks authoritatively but it seems like the author has not thought this through. Unless the exploit can easily deposit the threat package onto the Mac before then executing it in a way that bypasses the Mac's built-in threat protection (such as Gatekeeper), this is not a viable vulnerability.

 

[Martin123]

The title seems rather clickbaity. It doesn't seem to me that there is any proof of concept that will "take over your Mac" if it hasn't already been so compromised that it contains a malicious executable at a location known to the attacker... Or is there a way of passing environment variables to executables via the URL?

 

[adamsc]

OK, I get that security is hard. I get that there are millions of lines of code in an operating system and things like this are going to fall through the cracks. Honestly, I do.

However, is it just me or is Apple getting particularly bad for this just recently? This. The recent iOS text message bug. The thing where you could get root without a password. Reading that Facebook post where it mentioned Microsoft going back to basics for security in the early 00s, I'm wondering if Apple need to do the same; dial back a bit on yearly OS releases and focus on security?

I'm not sure how much it's really changed: they've always had gaffes like this — years back I got a couple of CVEs against OS X for things like dialing SSH key validation or TLS certificate checks — and unfortunately it's far from unusual in the industry (Microsoft has had some high profile botches recently, including those print and Exchange ones which took a shocking amount of time to patch for real).

I think there are two big trends here: there's a ton of demand for developers but companies typically resist paying for training or slowing down new feature velocity so you have the combination of lots of changes being pushed out and limited review or testing by people with significant security experience. This is not helped at all by the “security is something we procure” mentality at many large companies where, at best, automated security tools are doing the brunt of the work because they aren't willing to spend the money and time needed to have humans dig in, especially before dodgy code has been proven to be exploitable.

The other big trend is that cryptocurrency has made it possible to have industrial-scale malware operations by making it easier to steal directly or launder ransom payments. That means that there's a huge amount of money funding highly-skilled professional attackers and that's larger than most organizations have to spend on defense. This means that there's both a lot more effort going in to finding problems and many software development teams will be spending their time dealing with incoming reports rather finding problems which haven't yet been discovered or are just being created. Until there's something like personal liability for executives many companies will continue to “save” by underfunding the defense side since it'd take a significant amount of money to really get ahead of the curve.

That last point doesn't apply to Apple, of course: they could just take one day's worth of iPhone profits and hire as many people as they need — which really underscores that this is a C-level failure. There are some things they should be doing as a general course of business: the most pressing need being rewriting everything network-facing like iMessage in a memory-safe language like Swift or Rust but, as this bug illustrates, there's no one thing you can do to prevent exploits (modern languages do substantially increase productivity and reduce the amount of code which has to be written and reviewed, of course). Security review and hardening has to happen all over your codebase while the attacker only has to find one path to be successful.

 

[adamsc]

The title seems rather clickbaity. It doesn't seem to me that there is any proof of concept that will "take over your Mac" if it hasn't already been so compromised that it contains a malicious executable at a location known to the attacker... Or is there a way of passing environment variables to executables via the URL?

The proof of concept in the linked write-up suggests that the mechanism would be using Terminal.app to run something like a shell command. I would also not be surprised if you could run one of the pre-installed scripting environments (JSC, Python, Ruby, Perl, AppleScript, etc.) with a little creativity.

The other thing I'd worry about is whether Mail.app saves all of the downloads for a particular message in the same location. They've moved all of that into the sandboxed container hierarchy under ~/Library using what appear to be per-message random directory names but I don't know whether that would mean that, for example, a message which had clickme.inetloc could run the totallynotmalware.sh attachment from the same message because they're in the same directory.

 

[sonolumi]

The title seems rather clickbaity. It doesn't seem to me that there is any proof of concept that will "take over your Mac" if it hasn't already been so compromised that it contains a malicious executable at a location known to the attacker... Or is there a way of passing environment variables to executables via the URL?

It's the B headline of the A/B thing Ars does. "Unpatched MacOS vulnerability lets remote attackers execute code", would be A.

 

[JerryFritschle]

The article references macOS 11.3.1. It is now at 11.6. This made me double-check the dateline of the story.

Is there any update on this?

 

[ColdWetDog]

The title seems rather clickbaity. It doesn't seem to me that there is any proof of concept that will "take over your Mac" if it hasn't already been so compromised that it contains a malicious executable at a location known to the attacker... Or is there a way of passing environment variables to executables via the URL?

The proof of concept in the linked write-up suggests that the mechanism would be using Terminal.app to run something like a shell command. I would also not be surprised if you could run one of the pre-installed scripting environments (JSC, Python, Ruby, Perl, AppleScript, etc.) with a little creativity.

The other thing I'd worry about is whether Mail.app saves all of the downloads for a particular message in the same location. They've moved all of that into the sandboxed container hierarchy under ~/Library using what appear to be per-message random directory names but I don't know whether that would mean that, for example, a message which had clickme.inetloc could run the totallynotmalware.sh attachment from the same message because they're in the same directory.

Exactly. Most *really bad* intrusions chain vulnerabilities together. You get your fingernail in the door with this one. Take the next step and the next.

Eventually you have something worse than the sum of the parts.

 

[i662i812r11]

In addition to the other comments about the article's overblown reaction it states this:

For example, opening an email that contains an inetloc attachment via the "Mail" app will trigger the vulnerability without warning.

Opening an email with the attachment does not trigger the flaw. Elsewhere in the article it states you have to click to open the attachment.

 

[Castellum Excors]

OK, I get that security is hard. I get that there are millions of lines of code in an operating system and things like this are going to fall through the cracks. Honestly, I do.

However, is it just me or is Apple getting particularly bad for this just recently? This. The recent iOS text message bug. The thing where you could get root without a password. Reading that Facebook post where it mentioned Microsoft going back to basics for security in the early 00s, I'm wondering if Apple need to do the same; dial back a bit on yearly OS releases and focus on security?

All vitriol aside, it used to be that PC users would be taunted by Mac users whenever Microsoft got hit by malware and the return salvo was always about how Apple had a small market-share and wasn't worth targeting. Now it appears they finally are, i.e. flaws have existed but were either kept off the radar or people simply didn't bother digging into it.

 

[Carewolf]

OK, I get that security is hard. I get that there are millions of lines of code in an operating system and things like this are going to fall through the cracks. Honestly, I do.

However, is it just me or is Apple getting particularly bad for this just recently? This. The recent iOS text message bug. The thing where you could get root without a password. Reading that Facebook post where it mentioned Microsoft going back to basics for security in the early 00s, I'm wondering if Apple need to do the same; dial back a bit on yearly OS releases and focus on security?

No, they have always been this bad. Which isn't all that bad compared to other companies. Just normal, which just seems to surprise some fans, but nobody else.

 

[kvothe_too]

As several people are pointing out, this article has several sensational errors.

For one, the portion of the title "Clicking this attachment will take over your macOS" is utterly false as written. At best it could become "Clicking an attachment could take over your macOS".

Also false or misleading is "Internet shortcuts come with code execution capability." They come with file open capability, not code execution. They have command execution capability but even that's misleading since it's one command: open URL. And that leads us to...

While a quote from someone else, this is false "...the commands it runs can be local to the macOS allowing the execution of arbitrary commands by the user without any warning / prompts". It does not allow the execution of arbitrary commands. The main problem is the word "arbitrary".

The following is of course false, as stated later in the article: "...opening an email that contains an inetloc attachment via the "Mail" app will trigger the vulnerability without warning." The user has to double click the attachment.

Come on, Ars.

 

[Aaron44126]

This snippet with just eight lines of code is what launched the Calculator shown above. But any skillful threat actor could modify this test code to execute outright malicious code on the victim's machine.

how, though? does the file: URI handler accept arguments in the command, or is there another way to provide the malicious payload? a drive-by download might work, but since macOS is Unix, wouldn't it require the execute permission bit be set on the file somehow?

(obviously, this is a serious security issue - i'm just curious specifically how an attack would work.)

This isn't in the ARS proof-of-concept, but if you can make it execute an app AND pass parameters to it, then you can do basically anything. Use the "rm" command to delete something critical from the system. Or use the wget command to download and run a malicious script, and installs a process to monitor you or something.

 

[ColdWetDog]

As several people are pointing out, this article has several sensational errors.

For one, the portion of the title "Clicking this attachment will take over your macOS" is utterly false as written. At best it could become "Clicking an attachment could take over your macOS".

Also false or misleading is "Internet shortcuts come with code execution capability." They come with file open capability, not code execution. They have command execution capability but even that's misleading since it's one command: open URL. And that leads us to...

While a quote from someone else, this is false "...the commands it runs can be local to the macOS allowing the execution of arbitrary commands by the user without any warning / prompts". It does not allow the execution of arbitrary commands. The main problem is the word "arbitrary".

The following is of course false, as stated later in the article: "...opening an email that contains an inetloc attachment via the "Mail" app will trigger the vulnerability without warning." The user has to double click the attachment.

Come on, Ars.

Come on Ars, indeed. This whole A/B debacle is a real black eye for the site. This is only one of dozens of similar, relatively recent, complaints about blatant click bait headlines. The sad thing is that it probably works, else they wouldn't do it and the whole point (as far a Conde Nast is concerned) is to get clicks.

But it is sad. What the authors can and should do is to be more restrained and accurate in their reporting. TFA is a little lite on that.

This isn't WIRED and Ars shouldn't be trying to emulate them.

 

[Deleted member 823177]

This snippet with just eight lines of code is what launched the Calculator shown above. But any skillful threat actor could modify this test code to execute outright malicious code on the victim's machine.

how, though? does the file: URI handler accept arguments in the command, or is there another way to provide the malicious payload? a drive-by download might work, but since macOS is Unix, wouldn't it require the execute permission bit be set on the file somehow?

(obviously, this is a serious security issue - i'm just curious specifically how an attack would work.)

This isn't in the ARS proof-of-concept, but if you can make it execute an app AND pass parameters to it, then you can do basically anything. Use the "rm" command to delete something critical from the system. Or use the wget command to download and run a malicious script, and installs a process to monitor you or something.

right, that's why i asked "does the file: URI handler accept arguments in the command" - but that seems like it would be an unusual design. either way i think the article could explain the exploit mechanism in a bit more detail.

 

[chabig]

While the threat landscape for MacOS is, over all, considerably lower than for Windows systems, I'm grateful to Ars for articles like this. You'd be amazed how many of my Mac users still regularly complain that we require security software because "Macs don't get viruses." Being able to quickly link management to mainstream IT publications like this means they believe me when I call bullshit.
(Edited for clarity)

Does your security software protect from the flaw described in this article?

 

[Matthew J.]

As several people are pointing out, this article has several sensational errors.

For one, the portion of the title "Clicking this attachment will take over your macOS" is utterly false as written. At best it could become "Clicking an attachment could take over your macOS".

Also false or misleading is "Internet shortcuts come with code execution capability." They come with file open capability, not code execution. They have command execution capability but even that's misleading since it's one command: open URL. And that leads us to...

While a quote from someone else, this is false "...the commands it runs can be local to the macOS allowing the execution of arbitrary commands by the user without any warning / prompts". It does not allow the execution of arbitrary commands. The main problem is the word "arbitrary".

The following is of course false, as stated later in the article: "...opening an email that contains an inetloc attachment via the "Mail" app will trigger the vulnerability without warning." The user has to double click the attachment.

Come on, Ars.

Come on Ars, indeed. This whole A/B debacle is a real black eye for the site. This is only one of dozens of similar, relatively recent, complaints about blatant click bait headlines. The sad thing is that it probably works, else they wouldn't do it and the whole point (as far a Conde Nast is concerned) is to get clicks.

But it is sad. What the authors can and should do is to be more restrained and accurate in their reporting. TFA is a little lite on that.

This isn't WIRED and Ars shouldn't be trying to emulate them.

I agree... write ONE headline, that accurately and concisely describes the topic of the article, WITHOUT clickbait--and stick with it.

This whole headline A/B nonsense is just stupid.

 

[Deleted member 823177]

As several people are pointing out, this article has several sensational errors.

For one, the portion of the title "Clicking this attachment will take over your macOS" is utterly false as written. At best it could become "Clicking an attachment could take over your macOS".

Also false or misleading is "Internet shortcuts come with code execution capability." They come with file open capability, not code execution. They have command execution capability but even that's misleading since it's one command: open URL. And that leads us to...

While a quote from someone else, this is false "...the commands it runs can be local to the macOS allowing the execution of arbitrary commands by the user without any warning / prompts". It does not allow the execution of arbitrary commands. The main problem is the word "arbitrary".

The following is of course false, as stated later in the article: "...opening an email that contains an inetloc attachment via the "Mail" app will trigger the vulnerability without warning." The user has to double click the attachment.

Come on, Ars.

Come on Ars, indeed. This whole A/B debacle is a real black eye for the site. This is only one of dozens of similar, relatively recent, complaints about blatant click bait headlines. The sad thing is that it probably works, else they wouldn't do it and the whole point (as far a Conde Nast is concerned) is to get clicks.

But it is sad. What the authors can and should do is to be more restrained and accurate in their reporting. TFA is a little lite on that.

This isn't WIRED and Ars shouldn't be trying to emulate them.

I agree... write ONE headline, that accurately and concisely describes the topic of the article, WITHOUT clickbait--and stick with it.

This whole headline A/B nonsense is just stupid.

when people were complaining about autoplaying video adverts for non-subscribers, the response from Ars was that the site was seriously struggling financially and, basically, "either we put autoplaying videos on the site, or we start firing writers". i suspect it'll be the same for the A/B headlines.

we might worry that poor or inaccurate headlines would drive existing readers away, but if the metric numbers go up, who can argue with that?

 

[Failed2Boot]

The title seems rather clickbaity. It doesn't seem to me that there is any proof of concept that will "take over your Mac" if it hasn't already been so compromised that it contains a malicious executable at a location known to the attacker... Or is there a way of passing environment variables to executables via the URL?

Edit: Proof of concept

 

[krg1757]

The title seems rather clickbaity. It doesn't seem to me that there is any proof of concept that will "take over your Mac" if it hasn't already been so compromised that it contains a malicious executable at a location known to the attacker... Or is there a way of passing environment variables to executables via the URL?

There are SEVERAL articles by Ax (a relatively new Ars contributor) which feel the same way or are similarly un-nuanced. Checking their bio on Ars which links to work on other sites, a short perusal didn’t give me hope. They may actually be a security researcher as claimed (and perhaps a good one) but I feel like if so, the articles they write are a side gig which leans hard into the “what can I get for limited investment” ideal. In other words, clickbaity.

Not the Ars I pay for, damnit.

 

[Paegan]

I tested this theory on my macOS Big Sur 11.3.1

WTF? There have been numerous security updates since then, and the current version is 11.6. Test it on that or change the title of the article to "Apple users warned: Not installing security updates is dumb".

I can't reproduce the proof-of-concept on Mojave 10.14.6 (which got a security update a few weeks ago). On older macOS Calculator.app is in /Applications not /System/Applications but even after correcting that double-clicking poc.inetloc does nothing.

 

[krg1757]

The title seems rather clickbaity. It doesn't seem to me that there is any proof of concept that will "take over your Mac" if it hasn't already been so compromised that it contains a malicious executable at a location known to the attacker... Or is there a way of passing environment variables to executables via the URL?

Edit: Proof of concept

…and one gif explains more than the entire article, sans some explanation of what the file is, its normal purpose, etc.

 

[jdw]

In general I agree that this article is sensationalizing more than a bit.

But here's my hot take:

file:// URLs shouldn't run anything. They're meant to open documents in a browser.

Worst case scenario, "FiLe:///////////////bin/pwd" should open a tab in Safari with H__PAGEZERO, a bunch of other executable-format gooblydook, and a ton of random binary characters.

How and when (and why?) did Apple go from that to executing anything but Safari (much less the file itself) based on them?!

(Also, I don't think file: URLs can be used to specify arguments since they're not meant to be executed. But who knows? Maybe the same code "helpfully" passes everything after the ? on the command line. Hopefully not.)

Not that I would click on anything .inetloc anyway. But I wouldn't do it because I'd expect whatever the 2021 version of goatse/2g1c is. Not because of this stupidity.

As for how to weaponize it, if we're coworkers I could put something executable in our shared Dropbox. It'll live in a predictable location well enough for me to email you the link, preferably from a third party's unlocked computer while they're in the bathroom.

 

[AmorImpermissus]

While the threat landscape for MacOS is, over all, considerably lower than for Windows systems, I'm grateful to Ars for articles like this. You'd be amazed how many of my Mac users still regularly complain that we require security software because "Macs don't get viruses." Being able to quickly link management to mainstream IT publications like this means they believe me when I call bullshit.
(Edited for clarity)

Does your security software protect from the flaw described in this article?

It will as soon as I finish adding a custom regex for the email and file OAS when I get to work! We use our RMM's MDM feature to block access to the native mail applications, and none of our users have root or admin access, even on Macs (much to their chagrin). However, if our RMM didn't have an Apple MDM integration, this would be completely infeasible to manage at scale.

 

[krg1757]

I tested this theory on my macOS Big Sur 11.3.1

WTF? There have been numerous security updates since then, and the current version is 11.6. Test it on that or change the title of the article to "Apple users warned: Not installing security updates is dumb".

I can't reproduce the proof-of-concept on Mojave 10.14.6 (which got a security update a few weeks ago). On older macOS Calculator.app is in /Applications not /System/Applications but even after correcting that double-clicking poc.inetloc does nothing.

Also cannot reproduce on Mojave 10.14.6; still salty about not getting the last update, so as far as I can tell, Mojave is even further behind than more recent major releases.

 

[silverboy]

Oh, Apple, not covering all capitalization cases? Has no one there ever written a unit test in their entire lives? [Gg]oto fail.