Apple tried to patch this security hole in macOS Finder but didn't consider upper and lowercase characters Apple's macOS Finder application is currently vulnerable to a remote code execution bug, despite an apparent attempt to fix the problem. A security advisory published Tuesday by the SSD Secure Disclosure program, on behalf of researcher Park Minchan, explains that macOS Finder – which provides a visual interface for …
This post has been deleted by its author
String comparison 101 - should it be case-sensitive, or case-insensitive. Always ask that.
At least 7 stages that should have picked this up!
Design
Design review
Specification
Specification review
Development
Code review
Testing
That it slipped past all of these unchecked is deeply concerning. This is fundamental stuff and no way it should have been overlooked by any but the greenest of greenhorns.
That only makes it worse.
Let's say it did go down like that... testing still should've caught it. Changes not tied to a defect or enhancement task simply shouldn't happen in a production environment, and testing should be performed on all defect and enhancement tasks.
Needs a tester with enough nouse to recognise whether case-sensitivity should be checked. They should check things match the spec too, but also need to be able to recognise when something might be missing from said spec.
If they're just test monkeys blindly following the spec, everything is prone to that single point of failure. Which is a management failing for allowing it to happen.
I presume your two downvoters are unaware that filenames on MacOS are not case sensitive, or not always, or not on some of the filesystems used over the years... This manifests in various _interesting_ ways, generally when you have the least time to spend on exorcising the bugs.
Why this? FiLe:////////////////////////System/Applications/Calculator.app
In my testing, three slashes are sufficient: FiLe:///System/Applications/Calculator.app
When I use only two slashes, the error message is "The internet location file `poc.inetloc` can't be opened because it's damaged." Okay, the URI is malformed (the spec calls for three slashes for file resources), that error message is close enough. But when I use three slashes and lower-case "file", the error message is the same. This indicates to me the fix was done in kludgy hack mode. What they *should* have done was create a custom error message to go with the new branch, along the lines of "Access to the resource `file:///path` has been blocked for security reasons."
The file:/// resources are still working for me in Safari bookmarks and in fileloc type files, so I guess I don't care what they do with inetloc type files -- I wouldn't be opening unknown resources from emails or downloads anyway.
This error message also known as the "Arrgh Apple error", because it's the thing that goes through my head whenever I see it. They use that message for anything they don't like in Finder. This means, for example, that they give you the same message for applications that they don't want to run for certificate reasons (you can bypass that by changing a setting and using the menu to open it, but it doesn't say that). People complain about Microsoft's "Something went wrong and here's a 32-bit hex value, have fun" messages, but as unhelpful as those are, they're at least truthful. "X can't be opened because it's damaged" is quite often an outright lie, but because they also give you that when something is really malformed, you can never know until doing your own investigation.
It says I can (theoretically) send you an e-mail with this in it. If you click on the e-mail, and why would you not, then (theoretically) I pwned you. Remote compromise.
This is different, of course, from you creating the compromise file on your own desktop and running it manually. For one thing, if you built the file yourself then you probably gave it permission to run. The bug is that it can run even without that permission.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
