Slashdot Mirror


Ex-NSA Researcher Claims That DLL-Style Attacks Work Just Fine On OS X

An anonymous reader writes Ex-NSA and NASA researcher Patrick Wardle claims to have developed a reliable technique of Shared Library replacement which renders Apple's OSX operating system just as vulnerable to exploitation as Windows has been (via its 'DLL' shared libraries) for years. Speaking at CanSecWest, Wardle explained that Apple's refusal to encrypt software downloads via its App Store allows an attacker on the same network to inject a malicious 'dylib' (shared library) without altering the hash of the legitimate-but-vulnerable software, thereby leaving the Developer ID signature intact. Wardle ran a crafted Python script on a typical Mac and discovered 150 dylib-dependent applications, including Apple's own Xcode developer environment — revealed last week by Edward Snowden to be a priority target for the NSA due to its ability to propagate compromised software.

93 comments

  1. Shouldn't that be sign? by LWATCDR · · Score: 1

    don't the shared libs need to be signed.
    Of course the problem is that when you make signing mandatory you make everyone pay for a cert.

    --
    See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
    1. Re:Shouldn't that be sign? by jones_supa · · Score: 1

      I assume something like Windows Resource Protection would also help? For core system libraries, at least.

    2. Re:Shouldn't that be sign? by Jeremi · · Score: 4, Informative

      don't the shared libs need to be signed.

      I was under the impression that as of MacOS/X 10.9.x, all distributed shared libraries in your .app directory needed to be signed as well, or Gatekeeper would treat the app as if it was unsigned. (See the "Code Signing Changes in OS X Mavericks" subsection at this link)

      Is the vulnerability described in the article applicable only to older versions of MacOS/X, or has the researcher found a way around that test?

      --


      I don't care if it's 90,000 hectares. That lake was not my doing.
    3. Re:Shouldn't that be sign? by Princeofcups · · Score: 4, Informative

      Is the vulnerability described in the article applicable only to older versions of MacOS/X, or has the researcher found a way around that test?

      Quoting the article: "It’s not a point-and-click exploit – the attacker will need to get on the same network as the target Mac, either through a breach or by sharing the same public Wi-Fi access point, and then inject a vulnerable but legitimate application and make some purely cosmetic changes to the appearance of the .dmg (virtual installer disk) file when mounted."

      Sounds pretty theoretical at this point. I don't see the "reliable technique of Shared Library replacement" that the summary declares.

      --
      The only thing worse than a Democrat is a Republican.
    4. Re:Shouldn't that be sign? by phantomfive · · Score: 4, Insightful

      It's complicated. On iOS, the libs all need to be signed and encrypted (the executable portions are encrypted, the metadata is not; so you'd need more than just correct hashing). On OSX, they need to be signed if you enable that in your settings (I haven't checked if the executables from iTunes are encrypted). The researcher is not being very clear. Note for example that the article says, "Wardle is also expected to release following his talk source code for a scanner that discovers apps that are vulnerable to his attack." Note that he didn't say he would release his proof of concept. Any of us can write a Python script that searches for .dylibs.

      So, there are several avenues for attack. One, you could replace a .dylib with one of your own. Secondly, you could append your own code to a .dylib. It's an old technique explained here. You can actually re-sign this and iOS will accept it and run it. Is this what the researcher is doing? He didn't explain.

      He claims to have gotten around the need for signing. How did he do that? In his demo, will he merely disable the setting that requires signing? It's hard to know if he doesn't release his proof of concept.

      I've looked through the mach-o .dylib loader code before, and it didn't feel tight at all. There is plenty of potential for an exploit, so I could believe he found one, but once again it's tough to believe this guy if he doesn't release his proof of concept.

      The fact that the guy is talking more like a PR representative than a researcher makes him suspicious.

      --
      "First they came for the slanderers and i said nothing."
    5. Re:Shouldn't that be sign? by phantomfive · · Score: 1
      Incidentally, in the mach-o file format, there is no way to 'load every dll in the directory' or 'load every dylib in the directory.' You have to explicitly list every dylib you want to load, including the full path (or starting your path with @appdirectory). So some of the things this guy says seem a little off. Like this one:

      He noted the attack should also work on downloaded .zip files that contain applications.

      That sounds like he's talking about unsigned applications. Which of course, if you replace a DLL with a different DLL, the different one will get executed. That's not really a vulnerability. He reportedly also thinks that Apple will have to re-architect OSX to stop this kind of attack. What? That is an eye-opening claim, I really want to see his proof-of-concept exploit because I doubt it exists.

      --
      "First they came for the slanderers and i said nothing."
    6. Re:Shouldn't that be sign? by bsDaemon · · Score: 1

      There's a difference between "reliable technique for script kiddies and Anonymous" and a "reliable technique used by foreign intelligence services who, if they want something bad enough are going to get it one way or another". For them, the "cyber attack" aspect is only one method and if it becomes untenable they'll revert to HUMINT means. Human infiltration or malicious insiders can be used to gain the access necessary to propagate the dylib injection attack and gain a more long-lasting digital foothold.

    7. Re:Shouldn't that be sign? by Anonymous Coward · · Score: 0

      Will have to ask Avery Ryan of CSI:Cyber.

    8. Re:Shouldn't that be sign? by Anonymous Coward · · Score: 0

      I extensively looked through the mach-o .dylib loader when I was fixing a bug while working for a very large company. It has undergone a LOT of changes in the name of security, so it may be a lot "tighter" than when you last looked at it, just a FYI.

    9. Re:Shouldn't that be sign? by phantomfive · · Score: 2

      It has undergone a LOT of changes in the name of security, so it may be a lot "tighter" than when you last looked at it, just a FYI.

      It's not. They added signing etc, but the quality of the code is still like this. If anything, it's gotten worse in the past few years IMO, as a lot of their good programmers have left.

      --
      "First they came for the slanderers and i said nothing."
    10. Re: Shouldn't that be sign? by Anonymous Coward · · Score: 1

      If the U.S. government had reliable HUMINT programs they might actually be able to catch terrorists, rather than relying on mass surveillance and a crap load of rockets.

    11. Re:Shouldn't that be sign? by HornWumpus · · Score: 1

      They leave things a little technical and obfuscated to slow down the script kiddies. You don't want to ship an exploit, just distribute the information.

      --
      John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
    12. Re:Shouldn't that be sign? by Anonymous Coward · · Score: 1

      As the Forbes article states, downloads from the Mac App Store are not vulnerable. Normal HTTP browser-based downloads (e.g. dmgs/zips) are vulnerable even if the user has GateKeeper set to only allow stuff from the Mac App Store (highest setting) - so its really just a GateKeeper bypass. I'll be releasing python code, a UI app (for scanning), slides and an in-depth technical white paper that describes everything in great detail :) Didn't want to give away all the details before the conf talk!

  2. You beat me to it. by Anonymous Coward · · Score: 0

    I was going to make a joke about this being a NSA feature and not an exploit, but it seems the article already did that.

    1. Re:You beat me to it. by Anonymous Coward · · Score: 0

      Lucky you didn't - such a comment really wouldn't have made any sense and would have marked you as someone who is trying too hard to be clever and follow the herd. The NSA is an intelligence gathering agency and not an entity that produces software for sale or use outside of their own organization. Therefore the concept of it ever adding 'features' to software is nonsensical. That meme really only is applicable to companies that produce and sell products to consumers and screw up their own products.

    2. Re:You beat me to it. by Eunuchswear · · Score: 1

      The NSA is an intelligence gathering agency and not an entity that produces software for sale or use outside of their own organization. Therefore the concept of it ever adding 'features' to software is nonsensical. That meme really only is applicable to companies that produce and sell products to consumers and screw up their own products.

      So you never heard about the NSA involvement in IPSEC or various other crypto standards, that in retrospect seem to be unnecessarily vunerable?

      --
      Watch this Heartland Institute video
    3. Re:You beat me to it. by Anonymous Coward · · Score: 1

      The NSA did SELinux and probably similar in OS X, which has strengthened the operating systems by a large margin... something running as root doesn't have full root access unless it has the right role.

      IMHO, the NSA isn't all bad. I'd say they have done more in keeping the bad guys out overall.

  3. Sign/crypt all up and downstream everything? by Anonymous Coward · · Score: 0

    If people "ON THE NETWORK" can modify unsigned bins/libs what can they NOT modify?

  4. Requires Almost Direct Access by macs4all · · Score: 1

    ...an attacker on the same network...

    In most scenarios, unless you have an NSA mole in your home/business, Isn't that basically the same as requiring direct access to the machine? Or are we just talking about "on the same planet" type of access?

    1. Re:Requires Almost Direct Access by NatasRevol · · Score: 1

      Given that they can have access to all the cellular networks....

      --
      There are two types of people in the world: Those who crave closure
    2. Re:Requires Almost Direct Access by WD · · Score: 1

      Have you ever connected to a network that wasn't yours?

    3. Re:Requires Almost Direct Access by Anonymous Coward · · Score: 0

      I would need to question closed sourced software makers, are they intentionally leaving holes in their software for this very reason? I find it very odd how simple yet stupid, one could leave a wide open exploit like this unchecked.

    4. Re:Requires Almost Direct Access by Anonymous Coward · · Score: 0

      In most scenarios, unless you have an NSA mole in your home/business
      Getting is not actually too terribly hard in most cases.

      Show up with a hard hat, clipboard, optional orange safety vest, and a 'work order'. That will get you into most places of business. It was what landed kevin mitnick in jail eventually. Many times they will even show you to the cupboard that holds the lines. I have seen pen tester computers the size of your small pinky. You do not need much. As once you are in you can leverage other assets to help you out.

      For your house most of the time you can change out the cable right outside the house and break in. You can even re-use your disguise. Sure you could be discovered fairly quickly but not before you did your damage. You may even be able to talk your way in to look at the computer if your truck looks official enough. White with a company logo sticker.

      Or they follow you around and find out you like to hook up to the local starbucks but you will not let them into your business/house. They can attack that site instead.

    5. Re:Requires Almost Direct Access by Anonymous Coward · · Score: 0

      This one proof of concept exploit requires direct network access.. However the vulnerability itself could likely be exploited any number of different ways.

    6. Re:Requires Almost Direct Access by Carewolf · · Score: 1

      ...an attacker on the same network...

      In most scenarios, unless you have an NSA mole in your home/business, Isn't that basically the same as requiring direct access to the machine? Or are we just talking about "on the same planet" type of access?

      No, it means someone has replaced your access point, impersonated it or you are connecting to a network that isn't yours.

      And no an encrypted WiFI doesn't help, the AP still has access to the unencrypted data.

    7. Re:Requires Almost Direct Access by halltk1983 · · Score: 1

      Or just one system on your network compromised by other means.

      --
      Watch for Penguins, they eat Apples and throw rocks at Windows.
    8. Re:Requires Almost Direct Access by ledow · · Score: 1

      This is the bit that makes me wonder about the "Update Cache" functionality on Apple devices where you can have a server on your local network that ALL devices behind that IP get their updates redirected to as soon as it's turned on.

      Basically, Apple Macs and iPads will do "WSUS-like" updates automatically from any local Mac server that appears to come from the same IP as the Mac/iPad in question. Without asking. Without the clients knowing. And with its own local cache of updates.

    9. Re:Requires Almost Direct Access by DarkOx · · Score: 1

      ...an attacker on the same network...

      I hate the language because its wildly in accurate. It should read an attacker on a network between yours and the servers, inclusive.

      Anyone who can MITM the traffic in anyway can use most vulnerabilities that are written up that way. I don't care if its thru some source routing, arp poisoning, packet capture off router or switch interface you traffic will traverse, maybe manipulating related traffic like DNS replies so you address them and they proxy; whatever. There are literally tons of ways.

      I think that language was just stuck in there by certain players to down play the seriousness of their 'remote exploits'

      --
      Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
    10. Re:Requires Almost Direct Access by macs4all · · Score: 1

      Have you ever connected to a network that wasn't yours?

      Yes, but there is a limit to my mis-trust.

    11. Re:Requires Almost Direct Access by CosaNostra+Pizza+Inc · · Score: 1

      Have you ever connected to a network that wasn't yours?

      Yes and whenever I do connect (to an untrusted network that isn't mine) from my laptop or from my Android-based Samsung Galaxy S5, I use the latest stable OpenVPN client to connect to a VPN server on my Rasberry Pi at home.

    12. Re:Requires Almost Direct Access by macs4all · · Score: 1

      I would need to question closed sourced software makers, are they intentionally leaving holes in their software for this very reason? I find it very odd how simple yet stupid, one could leave a wide open exploit like this unchecked.

      Yeah, that's right. Now go put another layer on that tinfoil hat.

    13. Re:Requires Almost Direct Access by macs4all · · Score: 1

      This is the bit that makes me wonder about the "Update Cache" functionality on Apple devices where you can have a server on your local network that ALL devices behind that IP get their updates redirected to as soon as it's turned on.

      Basically, Apple Macs and iPads will do "WSUS-like" updates automatically from any local Mac server that appears to come from the same IP as the Mac/iPad in question. Without asking. Without the clients knowing. And with its own local cache of updates.

      Then I guess most of us are safe; because there are virtually no "Apple Mac Servers" in use, anyway.

      And are you talking about "Net Boot" stuff? Because that is even more rare.

      And what do you mean by "comes from the same IP?" By definition, that is essentially impossible.

    14. Re:Requires Almost Direct Access by Imagix · · Score: 1

      _And_ download new software? No.

    15. Re:Requires Almost Direct Access by zlives · · Score: 1

      yayy you and 3 other guys that are protected maybe!!
      chances are your other family members are probably not so secure and they may introduce devices to your network that are compromised.
      the correct answer is give up :)

      not give up security but just the internet... i hope this pigeon reaches /.

    16. Re:Requires Almost Direct Access by zlives · · Score: 1

      yayy looks like the redundant pigeon made it, lost one to MITM... poor Louis you will be missed.

    17. Re:Requires Almost Direct Access by ledow · · Score: 1

      Er... never heard of NAT? Or IP spoofing?

      And, no, it's not related to the Net Boot things.

      Update Cache basically is a way to deploy a Mac server on your network and stop all the iPads/iMacs on site trying to update from Apple directly.

      The server advertises itself to Apple, who then redirect ANY machine that seems to have the same IP to update from the specified update server. For OS X updates, iOS updates, even apps. Basically, one "Apple Server" (or something that advertises itself as such) on your local network (or appearing to come from your IP) and you can push updates to all Apple devices on that network.

      Sure, there's probably encryption and hashing and verifying and all that supposedly going on, but now Microsoft are copying this same idea for Windows 10 - having workstations push updates to other workstations. At that point, you better hope the verification code is good if your machine can get instructed to update from another location as if it were Windows Update or Apple iTunes, transparently.

    18. Re:Requires Almost Direct Access by MachineShedFred · · Score: 1

      Except that if you are using the Software Update Service that is part of OS X Server, you either have to MITM DNS and re-point swscan.apple.com to your box, or you have to enroll all the Macs you want to redirect to the Profile Manager service on the same server (or another MDM profile you've created with something) that tells it to get it's software updates from that location. Or, if you want to go old school, you'd need to edit the /Library/Preferences/com.apple.SoftwareUpdate.plist file and add a CatalogURL entry that points to it.

      There is absolutely ZERO "automatic repointing" going on. And, the Software Updates are signed by Apple anyway.

      --
      Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
    19. Re:Requires Almost Direct Access by macs4all · · Score: 1

      Sure, there's probably encryption and hashing and verifying and all that supposedly going on,

      So, IOW, you have no idea as to what the security measures are that Apple has put into place, and you are simply speculating that it would be insecure is ridiculous.

    20. Re:Requires Almost Direct Access by mlts · · Score: 1

      Isn't Update Cache similar to WSUS? This makes sense since LAN bandwidth is almost always a lot more plentiful than having every box pull their updates via the Internet.

      AFIAK, Apple's updates are signed, so if someone does tamper with the update cache server, it will be detected.

    21. Re:Requires Almost Direct Access by konohitowa · · Score: 1

      It would seem that way. I haven't looked at the protocols, but I do have the OS X Server app ($19.99) running on a Mini on my home network with the caching functionality turned on. It appears to be nothing but a CDN that caches various Apple downloads (software, media..) locally and acts similarly to a transparent proxy. I wouldn't be horribly surprised if it was running Squid, but - like I said - I haven't looked at it. So if we're now at the point that content caching is anathema, then we'd better all just unplug from our ISPs and start sneaker netting everything. Or something.

    22. Re:Requires Almost Direct Access by macs4all · · Score: 1

      if we're now at the point that content caching is anathema, then we'd better all just unplug from our ISPs and start sneaker netting everything. Or something.

      Exactly.

  5. HTTPS? by Anonymous Coward · · Score: 3, Insightful

    I tend to agree with Apple on this one; there shouldn't be any need for HTTPS as the contents of the packages aren't meant to be secret. If this researcher was successful in his attempts to replace the shared libraries in a dmg package the problem is that the installer isn't checking for the signature on the dmg, or individual signatures of files within.

    tldr; so long as proper signatures are in place and handling is observed traffic interception is not a problem as it will be caught and the hijacked package discarded.

    Note that proper signatures are more secure than HTTPS, as the trusted Root CA list is necessary for HTTPS to work, and who really thinks that Verisign or the like would turn down a request from the US Government?

    1. Re:HTTPS? by Anonymous Coward · · Score: 1

      the contents of the package may not need to be secret, but people may not want the NSA to know which packages they're installing.

    2. Re:HTTPS? by Anonymous Coward · · Score: 1

      Good point, but afaik https "get" request isn't going to be encrypted, only the result of the request.

    3. Re:HTTPS? by ledow · · Score: 1

      How do you obtain the expected signatures to match against the package if not by HTTPS or similar?

      As you point out, if Verisign is happy to oblige, then the signatures can be altered in-transit as easily as the packages here, and there'd be no warning.

      It only takes one Apple-signed developer package in the hands of someone with this kind of access to fake the origin and authenticity of the package signature AND package if the connection itself isn't secure.

    4. Re:HTTPS? by Anonymous Coward · · Score: 0

      You are wrong. All the headers are encrypted. The only information leaked is the domain name (so vhosts work).

    5. Re:HTTPS? by Anonymous Coward · · Score: 0

      afaik https "get" request isn't going to be encrypted,

      As Mark Twain said, "the problem isn't what you don't know, it's what you know that ain't so". HTTPS is encrypted both ways, which is what makes it safe (relatively speaking) to send your ID and password with it even as part of a GET request.

      From Wikipedia: "Because HTTPS piggybacks HTTP entirely on top of TLS, the entirety of the underlying HTTP protocol can be encrypted. This includes the request URL (which particular web page was requested), query parameters, headers, and cookies (which often contain identity information about the user)." Of course it goes on to note that the TCP/IP parameters (IP and port) aren't so protected (which is one reason why things like TOR exist).

    6. Re:HTTPS? by Anonymous Coward · · Score: 0

      HTTPS should be used anyway, just because any information of value should be sent over SSL/TLS if only as a mechanism to prevent in-flight tampering (ad injection, etc.)

      What I don't get is why operating systems don't have an option for an executable manifest database. This goes hand in hand with the install mechanism:

      1: The foo package is chosen for install.
      2: The signature is checked, proper authorization is given, either by prompting the user or via another signature and a remote push mechanism.
      3: The files are copied and scripts run.
      4: All executable files, be it scripts, libraries and actual executable code has a hash created, and these hashes added to the OS's database.

      This way, if a library gets corrupted by any method (bit rot), execution can be stopped at once.

      However, even more secure...

      Lets just get rid of the idea of dynamic libraries totally? ZFS, NTFS, and hopefully btrfs have deduplication... why not just have all executables be static and have the filesystem deduplicate the parts with the same code segments? This will mean a lot more security since the OS just needs to worry about one executable entry point rather than potentially hundreds of library files.

    7. Re:HTTPS? by jeremyp · · Score: 2

      Not even that. You can't do generalised virtual hosting with SSL.

      The host header is just a header like any other so the server can't figure out which certificate to use to set up the encryption layer. It is possible to do it in a restricted set of circumstances with a wild card certificate that matches all of the virtual hosts.

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
    8. Re:HTTPS? by tlhIngan · · Score: 1

      How do you obtain the expected signatures to match against the package if not by HTTPS or similar?

      As you point out, if Verisign is happy to oblige, then the signatures can be altered in-transit as easily as the packages here, and there'd be no warning.

      It only takes one Apple-signed developer package in the hands of someone with this kind of access to fake the origin and authenticity of the package signature AND package if the connection itself isn't secure.

      The packages are signed by Apple using a key provided by Apple. That's what Apple's trusted developer program is about.

      As for your solution of provided an alternate signed binary? That was always true even in the normal case. OS X accepts two kinds of apps by default - Mac App Store apps and apps signed by a developer using a certificate provided by Apple. The latter is for those programs that aren't in the MAS for one reason or another (perhaps they were rejected, or the developer doesn't want to go through the process - whatever).

      But that "vulnerability" of being able to use it to sign malware has been there from day 1 since Apple doesn't control what developers use their certificate for. In fact, there has been at least one malware attack that used a legitimate developer certificate - Apple revoked it the next day which meant the malware couldn't run anymore. (No word if the developer got a warning about it - since you paid $99 for the certificate, Apple has payment information that tracks every developer who signed anything).

      A more Linux example would be someone who replaced a package in a repo with a modified one and got it all re-signed. There's no real way around it - the files are legitimately signed so as far as the computer is concerned, it's all kosher.

      It isn't a TOC-TOU (time of check - time of use) problem, it's basically replacing one signed binary with another. About the only thing an installer could do is check that the files it installs are signed with the same certificate - otherwise well, if you wanted to, you could pay Apple $99 and sign your malware with it.

    9. Re:HTTPS? by Bengie · · Score: 1

      Deduplication is at the block level. You would need to have all of your code segments block aligned, which could be an issue since block sizes vary from 512bytes to over 1MB depending on your FS and how you formatted it.

    10. Re:HTTPS? by mlts · · Score: 1

      Depends on filesystem and device. One SAN vendor (forgot name, but sells all SSD units) purports to be able to dedupe code even if it doesn't align at the same boundaries. It does a block level dedup on a write, then has a background process which does the file level deduplication after the data is on the disks.

      If this could be done in software (and hopefully not sacrificing performance or reliability), having every executable on the system static would simplify things on that level.

      The advantage of moving to this is that is simplifies software management. No /usr/lib needed. It also simplifies file isolation since an executable can be given a jailed, chrooted filesystem without any need to worry that it won't have a core routine available. It also gets rid of the "DLL hell" which has not just plagued Windows, but also UNIX variants.

    11. Re:HTTPS? by Anonymous Coward · · Score: 0

      Then a bug fix to a shared library would mean you'd have to redownload every application using it instead of just downloading a fixed shared library once.

    12. Re:HTTPS? by Cramer · · Score: 2

      Newer SSL standards include a host hint in the client-hello. So, yes, virtual hosts do work with https. (and have for MANY years now.)

    13. Re:HTTPS? by patrickwardle · · Score: 1

      For non-app store downloads, Gatekeeper is supposed to be this check (e.g. the user can say only allow signed apps or only apps from the app store). So yes, any HTTP download can be modified - the vulnerability here, is that Gatekeeper can be bypassed to run the injected unsigned code, even if the user had set Gatekeeper to only allow code from the Mac App Store.

    14. Re:HTTPS? by Anonymous Coward · · Score: 0

      Actually, I'm not worried about Verisign and the US Gvmt.
      I'm worried about the 10,000 other root CAs around the world who can sign certs for any server, anywhere, at any time.

      If any 1 of them is untrustworthy - or even hacked - and who doesn't think at least 1 of these CAs is hacked - HTTPS is vulnerable.

      It is especially vulnerable on networks where the local government controls the DNS ... you know - Turkey, China, Thailand, Singapore, India, Pakistan, Egypt, UAE, ... just think of the places where the government performs censorship through technology, not legal mandates.

  6. Obvious, once exposed, but not hard to patch by Anonymous Coward · · Score: 0

    If they don't want to sign the dll's, then at least they should be able to provide the MD5 checksums for them so folks can check if their machine has been compromised.

    It would seem that Apple would want to get ahead of this before their security mojo is exposed as not so strong.

    1. Re:Obvious, once exposed, but not hard to patch by Eunuchswear · · Score: 1

      If they don't want to sign the dll's, then at least they should be able to provide the MD5 checksums for them so folks can check if their machine has been compromised.

      MD5's? Do you work for the NSA or something?

      http://www.hotforsecurity.com/blog/md5-hash-broken-via-collision-attack-of-less-than-1-10775.html

      --
      Watch this Heartland Institute video
    2. Re:Obvious, once exposed, but not hard to patch by fnj · · Score: 1

      I think he probably meant SHA512 hash, but didn't know he meant it.

    3. Re:Obvious, once exposed, but not hard to patch by Anonymous Coward · · Score: 0

      Odds are checking the hash is just a safety blanket. You're protecting against an attack of downloading the wrong thing, by checking against a hash that you ... um, download, and see if it matches?

    4. Re:Obvious, once exposed, but not hard to patch by Anonymous Coward · · Score: 0

      Said libraries are already signed. Applications are already capable of checking those signatures at launch time. The only way this attack could work is if a developer has turned off checking signatures.

    5. Re:Obvious, once exposed, but not hard to patch by Anonymous Coward · · Score: 0

      Not trying to be obtuse, but what about MD5 plus filesize? Are two hashes (md5+sha) better than one? Being as you have to collide both at the same time?

    6. Re:Obvious, once exposed, but not hard to patch by mlts · · Score: 1

      Two hashes are better because if one algorithm fails, you have a backup. However, with CPU and I/O time so precious in most cases, two hashes are not really feasible.

      Were I going with an algo, I'd be using SHA3 or Skein, something that is as secure as one can get presently.

  7. 'DLL'? by Anonymous Coward · · Score: 0

    Why is DLL in quotes? Is it an attack that utilizes DLL's or not?

    1. Re:'DLL'? by Anonymous Coward · · Score: 0

      Typically 'DLL' is the term used for windows dynamic link libraries as they have that 3 character extension. Unix systems typically refer to these as shared libraries, and they typically have .so (shared object) file extensions.

      Same idea in principle, but not really the correct term.

  8. what about Linux by FudRucker · · Score: 1

    there are lots of shared object files in /usr/lib/[some-file-name].so

    arent those the equivalent of dll files? or close to it?

    --
    Politics is Treachery, Religion is Brainwashing
    1. Re:what about Linux by Anonymous Coward · · Score: 0

      Yes, but with version control possible. When windows updates a dll, you get the new one even if you don't want it unless it uses a different name. Linux you can link to a specific version, or just link to the dynamic link pointing to the newest version if you would like.

      They work more like assemblies in the GAC for Windows (without the signing requirement). I think the libraries in Linux are loaded into each process, so you will have many copies of the same one around in memory.

    2. Re:what about Linux by KiloByte · · Score: 1

      Yes, .so are exact equivalents of .dll, but as all major distributions sign packages as whole, this attack can't be used.

      --
      The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
    3. Re:what about Linux by Bacon+Bits · · Score: 1

      I'm not sure what you mean by "sign packages as a whole" since that wording is somewhat ambiguous, but apt, at least, doesn't sign individual packages. The only signature in place for secure apt is the one placed on the package file listing in the repository. That signed file contains the list of checksums (MD5, SHA1, and SHA256) for each package archive in the repository.

      --
      The road to tyranny has always been paved with claims of necessity.
    4. Re:what about Linux by jones_supa · · Score: 1

      Yes, .so are exact equivalents of .dll, but as all major distributions sign packages as whole, this attack can't be used.

      The problem still remains that after the package has been installed, a file in it can just be replaced with a malicious version either on disk or in memory.

    5. Re:what about Linux by Anonymous Coward · · Score: 0

      I think the libraries in Linux are loaded into each process, so you will have many copies of the same one around in memory.

      Exactly. That's why they're called shared objects. (Eyeroll.)

      There's only one physical copy of a given .so in memory no matter how many processes are accessing it, but each process maps it to a virtual address in its own virtual space.

    6. Re:what about Linux by Imagix · · Score: 1

      You can replace the executable too. This part is blazingly obvious. The more "interesting" part is apparently replacing the file as it passes by during download.

    7. Re:what about Linux by 0123456 · · Score: 1

      The problem still remains that after the package has been installed, a file in it can just be replaced with a malicious version either on disk or in memory.

      To do that, you need to be root. If you're root, you can do anything you want.

  9. So everyone's pwned? by Anonymous Coward · · Score: 0

    If I understand the article right, a/c is saying that 150 different black hats have pwned most macs

  10. Laugh by koan · · Score: 1, Insightful

    renders Apple's OSX operating system just as vulnerable to exploitation as Windows has been

    Another arrow for my quiver, and I get to say I told you so.

    Shit has always been insecure, remember? It relied on the fact almost no one used Apple "security through obscurity".
    https://pbs.twimg.com/profile_...

    --
    "If any question why we died, Tell them because our fathers lied."
  11. Paranoia intensifies by MacDork · · Score: 3, Interesting

    XCode is pwned. Android Developer Tools are unsigned. The Android SDK and tools are unsigned. That makes me sad because I work with these tools. I can assume my systems are all pwned at this point and act accordingly...

    1. Re:Paranoia intensifies by phantomfive · · Score: 1

      You can build the Android SDK yourself. A lot of open source downloads will tell you the MD5 hash when it downloads it, and I believe Ubuntu actually verifies the hash.

      However, both Apple and Google are compromised by the NSA, so even if they were signed, it wouldn't matter.

      --
      "First they came for the slanderers and i said nothing."
    2. Re:Paranoia intensifies by phantomfive · · Score: 1

      Also, the Android SDK is downloaded over https, so you don't need to worry about this attack.

      --
      "First they came for the slanderers and i said nothing."
    3. Re:Paranoia intensifies by Anonymous Coward · · Score: 0

      The md5 hash is mostly for historical reasons at this point, or to verify that a file isn't corrupt -- if someone can replace the file you're downloading with another, then they can surely replace the hash on the website. You're overthinking it -- a bit like the criminals that figured out that you can leave DNA if you lick the envelope, so they tape the thing shut and forgot that they just left a near-perfect fingerprint.

    4. Re:Paranoia intensifies by Anonymous Coward · · Score: 1

      I would suggest switching to a Yubikey NEO for OpenSSH. https://www.yubico.com/products/yubikey-hardware/yubikey-neo/

      That way your key isn't recoverable by anybody, including yourself. Assuming the Yubikey hardware isn't flawed. The downside is that because you literally cannot back up the key, you really should purchase two of them, cross-sign them for revocation, add both keys to all your authorized_keys files, and keep one in storage in case you lose your primary/

      While it's plugged in it could still be used without your permission--a key logger could record your PIN. But it's the best thing out there. There are smartcards that have a physical button that must be depressed for signing, but getting them to work is complex and maddening. And if it's complex, you have little confidence that it's working properly--last time I tried OpenSC, for example, I couldn't really tell whether it was using my smartcard's crypto chip, or falling back to storing and reading the key from flash storage. By contrast, the Yubikey NEO works out-of-the-box with GnuPG's built-in OpenPGP Smartcard support, and GnuPG also comes with an OpenSSH-compatible ssh-agent.

      And the new Yubikey NEO works with the U2F Web authentication framework. Although I'm not sure if you can use the OpenPGP-compatible mode and the U2F-compatible mode at the same time. But in any event, U2F provides a framework for authenticating to websites using PKI, but which doesn't involve SSL client certificates.

      In case you're wondering, no, I'm not a Yubikey salesmen. I had just been waiting over 10 years to finally have a secure solution for SSH authentication I could be confident in. And I really hope U2F gets off the ground. People who think cellphones suffice for two-factor authentication are idiots. The only difference between your cellphone and your regular computer is that it's probably easier to hack the cellphone.

    5. Re:Paranoia intensifies by mlts · · Score: 1

      Yubikey looks interesting, but I've used eTokens in the past (generated a key on a computer with FDE, imported the key into three tokens, then physically destroyed the HDD that had the key on it since it was giving SMART errors anyway), as a way to have physical security of keys (if I have the three tokens, I know the key isn't going anywhere.)

      eTokens served me well, although it is impossible to find PKCS drivers for them for newer Windows and OS X versions these days.

      They also serve as great ways to counter brute force attacks on a machine with FDE if using PGP's whole disk encryption (no token, no unlock key for the HDD unless one has a WDRT, or whole disk recovery token, stashed away.)

    6. Re:Paranoia intensifies by AHuxley · · Score: 1

      Re" That makes me sad because I work with these tools. I can assume my systems are all pwned at this point and act accordingly..."
      Yes write any messages on paper, covert to a one time pad and then enter that into the compromised hardware, software, OS, crypto and network.
      Consider future hardware and software buying re tame brands and their help with the world wide wiretap.

      --
      Domestic spying is now "Benign Information Gathering"
  12. Mac OS safer han Win... by Anonymous Coward · · Score: 0

    Uh... I'm sure quite a few Apple® fanboys will require Preparation H®, after being mocked by Microsofties; after this came to b light.

  13. Too Much Spying by JimSadler · · Score: 1

    The degree of response by our government to terrorism does not seem to be justified. We did lose some large buildings and a few aircraft but considering the size and nature of the US the 9/11 attacks were simply a very limp effort and came far from doing major damage to our nation. The three trillion dollar expense of our wars in the mid-east have surely done us more harm than the attacks. And one can only wonder about the massive expense of all the spying that is going on. I also wonder why, considering all the information police agencies have gathered why we are not seeing huge numbers of arrests for mundane criminal activities. One would think that drug dealers and drug runners would be buried under our jails already. And income tax cheats as well as those who make a living from crime should be vanishing as well. With data mining how hard can it be to find people who are living well beyond their reported income?

    1. Re:Too Much Spying by Anonymous Coward · · Score: 0

      Because the real purpose is, obviously, not what they say - and most assume - it is. Connect the dots.

    2. Re:Too Much Spying by Anonymous Coward · · Score: 0

      If you'd read any of the many news stories on slashdot about the sophistication of the mexican drug cartels you'd have realized that the drug distribution network is probably incredibly complex. I doubt there's much if any paper trail.

    3. Re:Too Much Spying by Livius · · Score: 1

      The purpose of the September 11th attacks was not to kill or destroy, but to cause the US to betray what few of its principles it still had and to pursue military misadventures that would create more enemies that they would eliminate. It was one of the most successful operations in all of human history.

      The purpose of the response to the September 11th attacks was to expand the surveillance powers of the US government, further the careers of second-rate politicians, and funnel public money to defence contractors. That was also successful in its goals.

  14. Good job, guys by Anonymous Coward · · Score: 0

    They've done some smart analysis

  15. Its really all about the numbers by Anonymous Coward · · Score: 0

    I think any OS could fall under a attack if the potential rewards are enough to warrant the effort. Apple's OS X has for years been irrelevant in numbers to justify the effort. Windows was simply there on most PC's and had end users that were more then ample. Now of course, we have seen a click up in OS X exploits because some now think the numbers are there. However, not to stick up for Apple or OS X, I do believe that this is still not a big deal for most Mac user. The focus is still on Windows until a more suitable and more vulnerable target comes along.

    1. Re:Its really all about the numbers by mlts · · Score: 1

      It would be nice to see some improvements in OS X security though just to keep ahead of the bad guys:

      1: A TPM chip that can be used with FileVault 2 for additional protection (so a Mac can be set to ask for a boot password which can be a log longer than the user password.) The TPM chip would also combat brute force attacks. Since all Windows 8.1 certified machines have to have a TPM 2.0 chip, and Apple uses x86 hardware, might as well use this functionality, as it is pretty much built into all new PCs.

      2: Apple should look into SED (OPAL SSC 2) functionality for their SSDs.

      3: If Apple can't put in a Kensington lock slot, then why not they design something for basic physical security?

      The goal isn't to keep away the guy with the blowtorch or plasma cutter, but so that one can be sitting at a table at a library, tie the laptop to the table, go use the restroom and come back, and the laptop would still be there. Yes, one can buy a PacSafe laptop bag that can be chained to an object... but shouldn't a multi-thousand dollar piece of gear at least have a little bit of design for anti-theft, even if it is a small piece of metal that flips out for a lock slot? Thin is in, yes... but Dells, HPs, and other laptop brands have similar dimensions of machines, but they can put a Kensington lock slot on their models.

  16. Mac App store not vulnerable by Anonymous Coward · · Score: 0

    From the article: "Wardle noted that apps from Appleâ(TM)s Mac App Store are not vulnerable."

  17. App Store Apps are Not Vulnerable by Anonymous Coward · · Score: 0

    AFAIK app store apps are not vulnerable.