Apple CORED: Boffins reveal password-killer 0-days for iOS and OS X Six university researchers have revealed deadly zero-day flaws in Apple's iOS and OS X, claiming it is possible to crack Apple's password-storing keychain, break app sandboxes, and bypass its App Store security checks. Attackers can exploit these bugs to steal passwords from installed apps, including the native email client, …
Apple stuff is supposed to be idiot-proof and I suppose it it is when used by idiots.
Unfortunately when used by anyone with even half a brain it appears to be wide open to abuse. And not to even respond to the reported threat is a real abdication of any duty of care to its users.
Not a nice prospect for those naive users who trust Apple implicitly.
Apple currently still has, on its app store, an app expressly stating that it is intended to be used to "bypass your school filter", etc. It's as simple as installing it, and you get full, free, VPN access to the outside world that's almost undetectable.
Not a huge issue, but there are no real ways to "block" a particular app install even with MDM APIs. You can turn app installs on or off and monitor them, but you can't blacklist an app. If you want to use, say, Cisco Meraki to push apps to your iPads in a school (a very popular choice) you need to have the "install apps" option on, or else you have to manually recall every iPad and do it manually every time.
The only real option you have is parental filtering, where you can block apps with certain age ratings.
The above app is STILL, after several reports, marked as being 4+. Apple have steadfastly refused to do anything about it, as they categorically state that it's nothing to do with them and it's up to the app-makers to decide the age-rating (not much point in having an age-rating, then, really?). This app allows bypass of any and all filters and access to the unfiltered Internet, for free, just by clicking "Get App".
However, Chrome was briefly pulled from the store and recategorised as 18+ because it "allows unrestricted access to the Internet".
Apple don't care about what they are doing, so long as they are making money. They are right and everyone else is wrong, and that's the end of it. And no amount of head-banging against their complaint department, tech support, etc. will do anything to change that at the moment.
The name of the VPN app : which one ? There are plenty on the app store, the one I use (VyprVPN) also has the 4+ rating. Of course, the apps are free, the subscription to a VPN service usually is not. But it's only that : a VPN profile. Browsing, mail, other apps : they use the VPN connection for access, nothing more. So any age limits on apps using that connection stay in place.
Apple currently still has, on its app store, an app expressly stating that it is intended to be used to "bypass your school filter", etc. It's as simple as installing it, and you get full, free, VPN access to the outside world that's almost undetectable.
If your school system can't stop VPNs, you're doing it wrong. Pretty much any corporate network I've had to plug into has blocked pretty much all VPN connection methods. Some proxies are even smart enough to detect "SSL" connections that have been transferring far more data than what a regular HTTPS request would require and cut off those connections.
Haha, good luck with that SSL method when the whole of the web goes SSL which is slowly happening.
Actually, that won't matter, since the method in question allows the proxy to act as a man-in-the-middle to decrypt the connections, inspect the contents, and reencrypt the HTTPS connections. They get away with this through the use of an internal CA pushed by default to all internal systems, such that the proxies are always trusted, even when they impersonate external HTTPS sites.
Evil. Pure evil.
"Some proxies are even smart enough to detect "SSL" connections that have been transferring far more data than what a regular HTTPS request would require and cut off those connections."
So what happens when a false positive complaint appears, such as someone trying to download a perfectly-legal Linux Live ISO? Plus I would think it would have a hard time trying to handle smurfed sessions or ones limited to small things that are plausible under normal web use.
So, the note about the Chromium team disabling the affected part escaped your notice?
You need bright light to find bugs. Delaying publication does not really improve security. Who's to say that other people (criminals, spies) haven't found the same vulnerabilities?
But neither does exposing updates too soon. You don't have to be smart enough to find a vulnerability if you can see what's changed in the latest patch and work back from there. And while some bugs are just simple errors that can be easily fixed others require core components to be redesigned and rewritten. Applying the same time scale to all vulnerabilities shows a lack of understanding of software development.
So it's a balancing act, allowing the vendor time to fix things in a timely manner is fine. Waiting six months seems a too generous to me though....
Enough. I'm absolutely sick of this bullshit. The way you fucking morons blather on is ridiculous. If you are a Goigle or Microsoft advocate, just shut the fuck up. Those to are demonstrably more complicit, despite Larry's protestations, than Apple. Open Sourcer? The code is fucking open!!! Do you really think that penetration of your systems is beyond the bods at the NSA's capability? Hubris is going to get the better of you and I for one cannot wait until it does you bunch of sanctimony pricks.
And breathe...
LOL! It's astounding how MS is evil, Apple and Google always right... MS has to fix everything in 90 days, Apple can ask for 180 (and is this fixed?) and nobody complains... if the vuln was already known in October 2014 and Chromium fixed it only recently, it took more than 90 days too... it's always easier to apply hard schedules to others than ourselves, right?
Delaying publication until a fix is ready - and the vendor is working on it - is a good thing - sure, somebody else can have found the same vulns, but maybe not. If you publish them, you ensure any criminal knows it and can use it easily. The day a vuln will hit you hard in the face, you'll change your mind...
LOL! It's astounding how MS is evil, Apple and Google always right.
What a load of crap! Time to burn your strawman!
Apple is known to have a terrible record on security updates. That's why many of those who use Macs don't really on Apple for POSIX libraries. Interestingly, however, it looks like they have learned from the openssl debacle and are moving to libressl for the next version.
Google might well want everybody's data but does have a good track record when it comes to bug-fixing. This may come from having a pretty good open source culture within the company: they have long been good players in many projects. The proof will, of course, come when someone discovers a major flaw in something like Android that they want holding back.
Not knocking the work, and certainly not the results, but when these guys say that this research will be invaluable for future reference, is that really the case ?
We all know about buffer overflows, yet that door is still open in almost every new malware report. Sometimes they even concern products made by big companies who definitely know better.
This new report is bringing to light some new obscure chain of consequences that constitute a vulnerability. Great news, but who exactly is going to pore over this to understand what is going on and how to avoid it ? Security researchers, not application coders.
When I search for "good programming practice", what I find is stuff that generally concerns code clarity and maintainability, rarely security.
In the best case, there will be a mention of using fgets instead of gets in C, because buffer overflow. But the rest is all about indenting, variable name formatting, function wrapping and commenting. Nothing to do with security.
We need an easy-to-read overview of good security practices that does not just say "check your inputs" but details what to check and how to make sure. Is that available somewhere ?
True, but I'm not even sure if this that much about programming. It sounds a lot more like design, especially Apple's much flaunted app sandboxing that seems to have been undermined.
Have you read the paper? It does discuss specific issues for app developers, even though the general problem probably can't be solved entirely at the app level.
In any case, saying this sort of research isn't useful for programmers is like saying research into the performance of building materials isn't useful for house builders. Yes, programmers are able to continue writing crap code. That doesn't mean it's impossible for them to learn to do better.
This post has been deleted by its author
The paper does criticise Apple for not making developers aware of the vulnerabilities or providing ways to spot them.
But, skimming the paper, I saw two classes of problems:
1. IPC is public. You'd be castigated for allowing access to private website data without forcing the user to login. The same applies to an app's internal services: if the service allows an app to change something or read sensitive data, then verify the caller is who they say they are. This includes communication via any url-scheme; so, for example, if your app can be reached via anglegrinder:param1¶m2&etc then any tom, dick or malicious app could do so. Also websockets, etc...
2. Impersonation. It's possible for one app to impersonate another. (They can register your keychain id and then steal your data. Or register your url scheme and intercept data before it gets to you.) The fixes for this are dependent on Apple, and will probably break apps. But avoid keychain until Apple have sorted it.
There wasn't a buffer overflow insight. These weren't programming errors, they were design errors. And for those of us who have been around the block, mitigation is plain common sense (AKA EXTREME PARANOIA).
We need an easy-to-read overview of good security practices that does not just say "check your inputs" but details what to check and how to make sure. Is that available somewhere ?
All over the place.
If you're programming in traditional procedural languages, try Howard et al., 24 Deadly Sins of Software Security. Originally 19 Deadly Sins.... I think the first edition came out in 2005, so it's been available for the past decade.
Organizations like SANS and OWASP have been publishing "top ten" vulnerability lists for years. The main SANS list goes back at least to 2000. The OWASP list is specifically for web applications, though some of the concepts are applicable elsewhere. OWASP has a good wiki and other materials that describe specific remediation steps. There are many, many online articles that discuss these lists and remediation steps for the vulnerabilities they describe.
There are the Security Focus mailing lists. Bugtraq is the most famous, but they have a "Security Basics" list, and in the early 2000s there was a "Security Programming" (SecProg) list; the archives are still available at securityfocus.com/archives, along with those for VulnDev and others. Back in the day there was plenty of activity on Usenet groups like comp.unix.security.
And of course there are any number of more-general treatments that will actually teach developers how to think about security and develop with it in mind, rather than simply following a list of rules. There's the O'Reilly Computer Security Basics book (Russell & Gangemi), for example, or Anderson's Security Engineering - which is available free online.
Give the problem with this flaw, Apple shouldn't need 6 months hell they knew about it for 9 months now still hasn't fixed it. Reason you say 1 months is to make Apple get off their butt and FIX IT. Problem is Apple has a nasty problem of NOT fixing stuff in a timely manner EVEN with ALL THE MONEY they make takes them months on end to fix an issue.
Problem is Apple has a nasty problem of NOT fixing stuff in a timely manner EVEN with ALL THE MONEY they make takes them months on end to fix an issue.
I don't see evidence of them NOT reacting to issues, but it is true that they sometimes take their time. The OpenSSL and bash bugs were nailed pretty quickly though, so I wonder why they took this long. Maybe the issue is too complex to patch quickly? It would be interesting to know.
I never said they haven't reacted to it, i said they have an issue getting things fixed in a timely manner. There was a flaw called flashback i think it was many years ago. Was a java exploit, 0 day bug that windows fix was out within a day, Apple had the updated code to fix it as well but took then 2 months before releasing the fix. Apple has a habit of taking a LONG time to fix nasty security flaw's. Its so bad that it would be easy to say Windows is 10x more secure then and Apple's OS's just on fact MS fix's things in a reasonable amount of time, where as apple you can't expect it to be fixed for least 2months if not more.
This post has been deleted by its author
A car with a serious flaw in its operation would be recalled and be fixed by the manufacturer or supplier in a time scale commensurate with the scale of the danger. If the scale of the fault is as great as losing passwords then a fast fix has to happen - or it might be better to turn the product off and not use it again until it is fixed.
would be recalled and fixed... sometimes.
Sometimes, in the past the mfr has decided its cheaper to settle the surviving family members' lawsuits than fix the flaw. Or just ignore the issue like with diesels' fuel filters, or VW Touran ABS modules and flywheels falling apart.
The article is generally better than Mr Pauli's dashes but still contains some misleading and poorly expressed parts. For example,
They found "security-critical vulnerabilities" including cross-app resource-sharing mechanisms and communications channels such as keychain, WebSocket and Scheme.
In this context "security-critical vulnerabilities" should not be quoted because it is in the context of the report. If the author wants to emphasise that this is a claim made by the researchers that has yet to be confirmed then more explicit context can be added: "the researchers claim that there are security-critical vulnerabilities…"
Resource-sharing is essentially what an operating does for applications and is always "cross-app". However, this sounds more like it is related to resources being shared between apps.
"Scheme" is a programming language, LISP like as far as I know but I'm probably wrong. Further down in the report this is clarified as referring to the URL-scheme used and not the programming language. BID is thrown in later without explanation of the acronym.
XProtect and app signing both work on filename metadata, if you strip it with a single xattr command you've lost protection.
Apple didn't backport the root pipe vulnerability to Mavericks or lower and the fix for Yosemite didn't really address the issue.
https://reverse.put.as/2015/04/13/how-to-fix-rootpipe-in-mavericks-and-call-apples-bullshit-bluff-about-rootpipe-fixes/
Yosemite networking is a disaster thanks to discoveryd.
Security fix policy is what we know by what's been updated rather than any official statement.
Now Keychain was owned six months ago and they've been unable to fix it.
It has rather gone downhill since Snow Leopard.
... if you have 2 processes running under the same user id on a system, then 1 process can attach to the other and scan its memory anyway. Which admittedly requires a large amount of knowledge of unix systems programming but the potential is there. How is this different other than some badly written libraries make it slightly easier?
"No, modern (post 1990s multi-user system) operating systems should manage the memory space for applications to prevent this."
I didn't mean read the memory directly, its needs OS support to bypass the standard memory protection. But it can be done otherwise debuggers, trace and profiling programs wouldn't work.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
