Slashdot Mirror


"Extremely Critical" OS X Keychain Vulnerability Steals Passwords Via SMS

Mark Wilson writes: Two security researchers have discovered a serious vulnerability in OS X that could allow an attacker to steal passwords and other credentials in an almost invisible way. Antoine Vincent Jebara and Raja Rahbani — two of the team behind the myki identity management security software — found that a series of terminal commands can be used to extract a range of stored credentials. What is particularly worrying about the vulnerability is that it requires virtually no interaction from the victim; simulated mouse clicks can be used to click on hidden buttons to grant permission to access the keychain. Apple has been informed of the issue, but a fix is yet to be issued. The attack, known as brokenchain, is disturbingly easy to execute. Ars reports that this weakness has been exploited for four years.

66 of 123 comments (clear)

  1. Wait for it... by KGIII · · Score: 1, Troll

    So who will defend Apple this time or attempt to minimize this or attempt to claim that other OSes are worse so that this is, seemingly, less significant. No OS is secure, it never will be and it only gets worse when you connect it to another device. There will always be security problems.

    Not because I care so much but because I am easily amused...

    --
    "So long and thanks for all the fish."
    1. Re: Wait for it... by Anonymous Coward · · Score: 2, Insightful

      Nobody should defend Apple, because it should require the user to enter the password to open the keychain. Instead of users being trained to blindly click to allow access, Apple let's the application writer approve their own accesses.

    2. Re: Wait for it... by KGIII · · Score: 1

      Somebody will if this is like very other thread on the subject. It seems to be a matter of pride. Use the OS that suits the task at hand best for you and practice safe hex. I suspect part of the problem has been the goal of making the computer a device for amusement instead of a computational device as its goal. Aiming for the lowest common denominator can not be a good thing in this field. It just can't be - at least not from my perspective. That's not to say it needs to be overly complex. Maybe it is time to go back to dumb terminals.

      --
      "So long and thanks for all the fish."
    3. Re:Wait for it... by cdrudge · · Score: 2, Funny

      Apparently this guy will, saying that no OS is secure, never will be, and there will always be security problems.

    4. Re:Wait for it... by kromozone · · Score: 5, Insightful

      Watch the video. The SMS is actually an MMS or instant message and he's downloaded a file called "Malicious.app" to the desktop. He then double clicks on that, the dock disappears, and very quickly the "Allow" button is clicked. By default OS X machines come set to allow only Applications from the Mac App Store to run. Most people reduce this security setting to allow applications from "Mac App Store and identified developers" to run. Either way, you'd have to 1) Not notice that this is a .App and not a picture, and 2) Have disabled the default security settings. Otherwise you'd get a big warning saying "You can't open this because of security settings", which would be pretty hard to miss and then you'd have to ignore the warning, change your security settings, re-open the file, not even worry about what the dialog saying "Allow" is and ignore the fact that your dock flashed on and off for no reason.

      I agree that you should be required to enter your password to access the keychain, but this is a guy from Beirut shilling for his password management company. Not only that, he doesn't mention which OS versions are affected or anything else. This could very easily be the NULL-pointer dereference exploit posted last week repackaged in a very clumsy way. If it is, why doesn't he say so? Post the exploit code at least so legitimate researchers can pick it apart.

      If you run around turning off security features and running random .apps from people willy-nilly on your computer, no matter what OS you're running.

    5. Re: Wait for it... by Anonymous Coward · · Score: 2, Informative

      It is only 9 lines of code: http://arstechnica.com/security/2015/09/attacks-accessing-mac-keychain-without-permission-date-back-to-2011/

      Then the app has all the accounts and passwords stored in your keychain.

    6. Re:Wait for it... by Anonymous Coward · · Score: 5, Informative

      Couple of comments :

      - it is a security feature. Apple only approves Apps if they go through the App Store - if they are merely signed by a developer, Apple has no involvement in approval, but there is a credit card identity verification strength chain back to the developer via the signing certificate, and the certificate can be revoked centrally. Thats changing the attack surface, and workable lifetime for the exploit, so it is reasonably to call it a security configuration feature.

      - OS X keychain and iOS keychain are different. In OS X, there are multiple keychains, and the level of access depends on configuration. Indeed there is no practical limit to the number of keychains in play. A standard user does not have access to the system keychain. Indeed your keychain doesn't need to be on the boot volume - paranoid OS X users put their keychain on an encrypted USB drive, and need to mount and unlock it , in addition to logging into the computer (so any credential on the drive is subject to 2FA to access)

      The actual "exploit" is _bordering_ on the old school "look at all the horrible things you can do if you have root access" exploits as though root access itself is the exploit.

      The attack does not work on the default configuration of the OS. In addition, it wouldn't work on a typical hardened configuration.

      If you run as an administrator, disable code signing, and explicitly enable the script, then yes it works, but those 3 things turn it from a 100 is percent of the installed base problem, into a much smaller problem.

      The

    7. Re:Wait for it... by sribe · · Score: 1

      By default OS X machines come set to allow only Applications from the Mac App Store to run. Most people reduce this security setting to allow applications from "Mac App Store and identified developers" to run.

      The default is to allow applications from Mac App Store and identified developers. But you're right about the rest.

    8. Re:Wait for it... by sribe · · Score: 4, Informative

      So all the user has to do is have zero understanding of the computer, click allow on everything with out thinking, and ignore stuff that is obviously weird and broken? Sounds like this will work against 30% of the population. Add in that it gets you free porn and you got 10% more.

      No. For an app from an unidentified developer, there is no "Allow" option presented. You have to know how to bypass that security setting in order to get the app to run, which is the whole point--the kind of users who blindly click "Allow" to everything are unlikely to know how to do that, and so won't be able to run this kind of app.

    9. Re:Wait for it... by Anonymous Coward · · Score: 1

      No, the default is app store only.

      2nd option is the one you said.

      3rd option is allow all apps.

    10. Re:Wait for it... by fleabay · · Score: 1

      If you run around turning off security features and running random .apps from people willy-nilly on your computer, no matter what OS you're running.

      brain fart?

    11. Re:Wait for it... by Malc · · Score: 1

      this is a guy [...] shilling for his password management company

      Thank you. From the tone/writing style of the story, I was wondering whether this was written by a first year CS student or somebody trying to sell something. More clutter adding to the poor SNR on /.

    12. Re:Wait for it... by AmiMoJo · · Score: 1

      It's being actively exploited in the wild: http://arstechnica.com/securit...

      The trojan app installs itself by clicking the "allow" button itself, so fast that the user doesn't have time to deny it permission. It installs adware on the user's machine without their consent.

      I'm surprised that Apple didn't use a special type of window for this request. On Windows the UAC requests are done in such a way that this couldn't happen - apps can't grab the window's handle and send simulated clicks.

      The SMS thing is strange though, you are right about that.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    13. Re:Wait for it... by Tough+Love · · Score: 1

      Top-poster much?

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    14. Re:Wait for it... by Tough+Love · · Score: 2, Informative

      Apologist? It's a bug. Real one. Even some gurus are going to get stung by this one.

      And you greatly overstate the difficulty of joe dumbass user googling to find out how to allow non-apple apps.

      Apologist.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    15. Re:Wait for it... by Rosyna · · Score: 2

      This is a malicious application (not an image) that has been allowed to run after the user dismissed the gatekeeper dialog that warns about downloading applications, after the user entered their password (to allow the malicious application to control other applications) and it's accessing a keychain item with no ACLs? How is that a flaw in Mac OS X?

    16. Re: Wait for it... by Rosyna · · Score: 2

      Those 9 lines won't actually run without entering an administrator's username and password first to permit Script Editor to control other applications.

      Try it.

    17. Re:Wait for it... by Rosyna · · Score: 1

      Apple does use a special type of window that can only be interacted with if a user enters an administrator's username and password.

      It says that's exactly what the user is doing in that Ars article. And UAC won't prevent an application running as SYSTEM from issuing commands that require SYSTEM.

    18. Re:Wait for it... by AmiMoJo · · Score: 1

      TFA shows an Applescript script that clicks the "accept" button. That doesn't seem very well protected.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    19. Re:Wait for it... by jeremyp · · Score: 1

      Can you name any? I have several games on OS X and none of them require me to disable Gatekeeper.

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
    20. Re: Wait for it... by Plumpaquatsch · · Score: 4, Informative

      It is only 9 lines of code: http://arstechnica.com/securit...

      Then the app has all the accounts and passwords stored in your keychain.

      Yes. If you give that script access first. IOW no, not really. If you instead block it, you have to enable it before it can even ask again.

      --
      Of course news about a fake are Fake News.
    21. Re: Wait for it... by Plumpaquatsch · · Score: 4, Insightful
      https://support.apple.com/libr...

      Note that the default is "Deny" and the only other options is "Open System Preferences" where you have to grant access to the app/script

      I can totally see how this could happen without the user noticing.

      --
      Of course news about a fake are Fake News.
    22. Re:Wait for it... by Plumpaquatsch · · Score: 4, Insightful

      Apologist? It's a bug. Real one. Even some gurus are going to get stung by this one.

      And you greatly overstate the difficulty of joe dumbass user googling to find out how to allow non-apple apps.

      Apologist.

      Yeah, exactly the same bug as giving an idiot like you access to a computer. Your post if proof of that. And no, this has nothing to do with" allowing non-apple apps" - not even with allowing any apps to run. Which you would have a chance of knowing if TFA didn't hide it behind a lot of scaremongering. But it's actually there. But hey, you at best only read the summary anyway, right?

      --
      Of course news about a fake are Fake News.
    23. Re:Wait for it... by Plumpaquatsch · · Score: 2

      The actual "exploit" is _bordering_ on the old school "look at all the horrible things you can do if you have root access" exploits as though root access itself is the exploit.

      Except for the fact that this does not need root access, did you actually read and understand this or did you just jump to Apple's defence?

      So far, so right. It's actually far more complicated than simply typing in your Admin password: https://support.apple.com/en-u...

      And the moral to the story: A) never trust the word of a security researcher who wants to sell you something, and B) you don't have to be a complete moron to be a Apple-Hater, but it sure helps.

      --
      Of course news about a fake are Fake News.
    24. Re:Wait for it... by sribe · · Score: 1

      Apologist? It's a bug. Real one. Even some gurus are going to get stung by this one.

      So, anyone who clarifies an error on this subject is automatically an apologist???

    25. Re:Wait for it... by Anonymous Coward · · Score: 1

      You fail as a developer if your solution is, don't let stupid people on computers.

    26. Re:Wait for it... by Penguinisto · · Score: 1

      The 'researchers' had to specifically and literally disable the default security protections on their machine in order to have that happen.

      Otherwise, it would have popped up a window refusing to run the application at all, instead demanding that you go into System Preferences to allow that specific application.

      It's like cutting the brake lines on a Toyota, then showing a video of it running into something while claiming that the car company has a serious brake design problem. :/

      --
      Quo usque tandem abutere, Nimbus, patientia nostra?
    27. Re: Wait for it... by Anonymous Coward · · Score: 1

      Actually, this 'bug' *does* require that the user enters a password. It requires that the user enters the *administrator* password to grant the malware app permission to control the computer. That has to happen *before* this attack will work. The attack 'works' because someone has explicitly granted root access to the malware.

    28. Re:Wait for it... by oh_my_080980980 · · Score: 1

      Ars will http://arstechnica.com/securit...: "Mac users should remember that the technique works only when invoked by an application already installed on their systems. There is no evidence the technique can be carried out through drive-by exploits or attacks that don't require social engineering and end-user interaction. "

    29. Re:Wait for it... by Tough+Love · · Score: 1

      Apple astroturfers with mod points churn my stomache.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    30. Re:Wait for it... by macs4all · · Score: 1

      If you run around turning off security features and running random .apps from people willy-nilly on your computer, no matter what OS you're running.

      Exactly.

      I would bet that the people that are on here declaring gloom and doom and "Apple doesn't care about Security", etc. are some of the very same people who will defend Android to the death when a user clicks-through the "Permissions" list when Installing an App, saying that it is the User's responsibility to be vigilant about granting Permissions.

      Guess what? Social Engineering works, and will likely continue to work, on certain people, and it is damn-near impossible to protect all users from themselves in all situations, and still have an OS that won't have everyone simply turning all security off, like with the first version of UAC on Vista. When the User says it's ok, then what else can be done if they hold the ultimate authority?

      So, if you were head of Security Development for OS X, what would you do that would actually work in all situations?

    31. Re:Wait for it... by macs4all · · Score: 2, Insightful

      The "security feature" in this case is just saying you want to run a program that Apple hasn't approved. I can already see the excuse for drive-by malware will be it is your fault for visiting a website Apple didn't approve.

      Even when you reduce the GateKeeper settings to the minimum, you still have to answer a Dialog that warns that this is an Application that was downloaded from the internet, and do you want to run it? THEN you have to specifically grant Sudo Permission.

      Seriously, what else would you have Apple do, that wouldn't have the Slashdot crowd whine that "You can't run non-Approved Apps"?

      Seriously. Damned if they do, and Damned if they don't. Security is, and always will be, a set of tradeoffs.

      That's not apologizing; that's recognizing reality, rather than holding something up to an utterly impossible, hypothetical ideal.

      If this was happening in Linux, they freetards would be all over blaming the User for being stupid. But when it's Apple, it is always their fault. Again, not apologizing; just observing the typical modus operandi around here.

    32. Re:Wait for it... by macs4all · · Score: 1

      No, the default is app store only.

      2nd option is the one you said.

      3rd option is allow all apps.

      But it is important to note that, even on the weakest setting, the User is still required to grant "First Run" privileges. So even if the User has done everything to de-fang GateKeeper, s/he still has to be "complicit" for the Exploit to Run.

      At that point, how much responsibility can be heaped on Apple, versus the User?

    33. Re:Wait for it... by fyngyrz · · Score: 2

      For conversation above the trivial level, context is relevant.

      So while you may hate it, you certainly aren't going to stop it.

      --
      I've fallen off your lawn, and I can't get up.
    34. Re:Wait for it... by Plumpaquatsch · · Score: 1

      Apple astroturfers with mod points churn my stomache.

      Actually, that's your ulcer. You still keep too much of that hate inside - go full postal.

      --
      Of course news about a fake are Fake News.
    35. Re:Wait for it... by lucm · · Score: 1

      Interlaced replies usually happen when someone tries to inject too many points in a single message. This shows poor aptitudes for synthesis and lack of focus, and does not facilitate communication as the exchange becomes a mess after only 1-2 replies. Shortsighted and sub-optimal.

      --
      lucm, indeed.
    36. Re:Wait for it... by fyngyrz · · Score: 1

      Nonsense.

      --
      I've fallen off your lawn, and I can't get up.
    37. Re:Wait for it... by Tough+Love · · Score: 1

      You just left a slime on the internet that won't wash off.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    38. Re:Wait for it... by doccus · · Score: 1

      I have used macs for years but I sure as hell won't defend Apple on this one. FOUR YEARS and they've said NOTHING? Instead, they withhold security updates for any system 3 years or more old. Frankly, I am dead sick and tired of the maroons that blame users for not using the very newest upgrade. Totally aside from the feeling of utter violation incurred from forced upgrades, the fact is that unlike Microsoft, Apple has recently gone out of their way to break applications on every new release, forcing developers to spend all their time that should be for coding new software, instead to repair the broken apps for free, usually.
      I've spent a considerable sum, on a disability income, over the years, on Photoshop and music applications, etc, and when Apple dropped power PC support via Rosetta 4 years ago, most of the devs had had enough, and upgrades were no longer free. Photoshop of course has never been, and just that alone is a grand. No, there is NOT a suitable replacement. I don't want to get into that whole "Gimp is just fine" bit, because it most certainly is not.
      Regardless, thios means that I have to use a 4 year old version of OSX, the last with PPC support, and yet , even though MS supplied security updates for well over a decade for EVERY version of Windows, ever, Apple refuses to supply security patches for anything over 3 years old. This is a huge security flaw, given that I can't be the only person in this position.
      And Mac anti-malware applications? Give me a break! Not worth the download.. I had a test file from some old AV program on my hard drive, and the only program that picked it up was Norton AV on OSX 10.1. ClamX AV didn't . BitDefender didn't . iAntivirus didn't, and the rest want MONEY for AV action when they don't even identify the few existing forms of malware. I know that's the case because there isn't a single report of anyone using these AVs who has actually FOUND a bug. If there was, it would be all over the web!
      Apple, and especially Tim Cook, for disrespecting your customers much that you leave it up to negligent third party developers to cover your ass, you should be utterly ashamed of yourself.

    39. Re:Wait for it... by Rosyna · · Score: 1

      Yeah, the AppleScript only works after the user has entered the administrator's username and password to allow it to use accessibility features to control other applications

  2. Do you even computer? by wbr1 · · Score: 4, Informative

    SMS? This is an apple script exploit on a mac PC. not a mobile device. Nowhere does the article explain that SMS is an attack vector and unless iOS is vulnerable as well,I do not see how it could be.

    --
    Silence is a state of mime.
    1. Re:Do you even computer? by bobthesungeek76036 · · Score: 2, Informative
      Yea I was having a hard time making the SMS connection. TFA speculates that SMS "could" be used to transmit the hijacked passwords:

      It is then possible to intercept a user's password and send it to the attacker via SMS or any other means

      pretty far stretch if you ask me...

      --
      Karma: Bad
    2. Re:Do you even computer? by wonkey_monkey · · Score: 1

      It is then possible to intercept a user's password and send it to the attacker via IrDA or any other means

      There. Much more relevant.

      --
      systemd is Roko's Basilisk.
    3. Re:Do you even computer? by Plumpaquatsch · · Score: 1

      SMS? This is an apple script exploit on a mac PC. not a mobile device. Nowhere does the article explain that SMS is an attack vector and unless iOS is vulnerable as well,I do not see how it could be.

      Actually, if you watch the video, the only thing you can really see is that Malicious App sends a SMS with the password it "stole" - via Twillo obviously: https://www.twilio.com/sms. But hey, clickbait is clickbait - and it worked. Oh, did it work.

      --
      Of course news about a fake are Fake News.
    4. Re:Do you even computer? by macs4all · · Score: 2

      SMS? This is an apple script exploit on a mac PC. not a mobile device. Nowhere does the article explain that SMS is an attack vector and unless iOS is vulnerable as well,I do not see how it could be.

      Not to support the obvious shill-article; but I believe that, since OS X 10.10 (Yosemite), Macs have been able to receive/send SMS and MMS messages that are routed through Apple's iMessage service.

      Having said that, I still believe that the amount of disabling of security by the User, and the Granting of Permissions by the User puts this Exploit solidly in the "Yawn" territory.

    5. Re: Do you even computer? by BitZtream · · Score: 2

      My iPhone is paired with my Mac and the Messages applications on my iPhone and Mac are linked as well. When my phone is near my Mac I do indeed get SMS messages on my Mac, as iMessage and Gtalk, other people probably do the same.

      Doesn't Android do that too with Hangouts or something?

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
  3. That's why I use Windows 10 by Anonymous Coward · · Score: 3, Funny

    No one is going to get my passwords. They've all been safely keylogged onto Microsoft's ultrasecure telemetry cloud!

    1. Re:That's why I use Windows 10 by t-wata · · Score: 1

      yeah, it is enough secure that only Microsoft can see the data..

    2. Re:That's why I use Windows 10 by Anonymous Coward · · Score: 1

      Passwords are protected at the bottom of the stairs.

  4. Vulnerability not really extremely critical .. by nickweller · · Score: 5, Informative

    "as long as a user had already allowed the app running the script to control the Mac .. the technique works only when invoked by an application already installed on their systems. There is no evidence the technique can be carried out through drive-by exploits or attacks that don't require social engineering and end-user interaction." ref.

    1. Re:Vulnerability not really extremely critical .. by Anonymous Coward · · Score: 1

      So just build it into any of the thousands of otherwise useful open source apps out there and wait for people to install it on their own. That approach has worked wonders in the past.

      User: "I wonder how my network is doing. Ooh this cool app will give me a list of hosts on my LAN and also tell me how much bandwidth my computer is using. Cool!" *click*. Done.

  5. Re:QQ moar by konohitowa · · Score: 2, Funny

    Gosh. You sure told them!

  6. Re:QQ moar by wbr1 · · Score: 1

    Hey turdnibble, it is a bad exploit...I'm no fanboi, juts pointing out the articles stupidity.

    --
    Silence is a state of mime.
  7. Egg asploded in your face again by Anonymous Coward · · Score: 3, Insightful

    Some of you clowns hate Apple so much, you will believe any unauthenticated negative you read.

    I'm mixed on Apple and not fan, but it is always funny watching the "See! See! Apple is insecure too".

    And then someone smart posts how ridiculous the claim is by explaining the several asterisks of the supposed exploit.

  8. The same basic approach works everywhere by Anonymous Coward · · Score: 1

    On OS X, this programmatically easier to do, but it's possible with a little more effort in Linux (if using GNOME or KDE and their password stores) and Windows (which is trickiest of all since you specifically deal with an application's store rather than a central one; presumably you'd go for a browser). the The trick is really just getting a user to run the executable in the first place.

    Note that you don't use SMS to attack, just to transmit the data. OS X makes it simple to use SMS, but other systems could use HTTP or e-mail just as easily. Using SMS is just for show (and probably not a good idea since the phone number appears in the script and is logged in the process).

    The big difference here is the OS X UI scripting makes the barrier to doing it much lower on that platform. A everyone's at risk.

    1. Re:The same basic approach works everywhere by gl4ss · · Score: 1

      the addition of sms into the article is bizarre. it almost sounds like a bizarre ios tie in to an article that has nothing to do with that.

      oh well, years old flaw.. so yeah, that's what it is.

      --
      world was created 5 seconds before this post as it is.
    2. Re:The same basic approach works everywhere by benjymouse · · Score: 2

      On OS X, this programmatically easier to do, but it's possible with a little more effort in Linux (if using GNOME or KDE and their password stores) and Windows (which is trickiest of all since you specifically deal with an application's store rather than a central one; presumably you'd go for a browser)

      On Windows - unlike on OS X and Linux - there is the concept of User Interface Privilege Isolation (UIPI) where a process running with a higher integrity level cannot be remote controlled by a lower-integrity process.

      The real vulnerability here is NOT whether the user has allowed the process to run or not or whether it came through the app store nor not. The critical vulnerability is the lack of isolation of the window that is supposed to obtain approval from the interactive user. This lack of isolation means that an OS X application can launch an action that requires approval and then immediately - through script - approve the action itself.

      Pointing to the app store approval model is missing the point entirely. Even approved applications can (and do!) contain vulnerabilities. The reason why so many apologists are out in force and try deflecting the problem as "app approval" is because this illustrate an architectural problem within OS X: Even though the same user runs a number of processes, a mechanism for policing what they can do to each other is lacking.

      --
      Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
    3. Re:The same basic approach works everywhere by Rosyna · · Score: 1

      It is isolated. In order to interact with it, a user must explicitly permit it by entering an admin's username and password.

    4. Re:The same basic approach works everywhere by TheRaven64 · · Score: 1

      It's pretty easy on anything running X11, where the authentication of things that are allowed to deliver arbitrary input events to other applications is 'oh, you're a program that can read this user's home directory or from a trusted IP address? Go right ahead! By the way, if you're not then you're not allowed to put windows on the screen.' Windows has a similar mechanism, but has a special category of window that can only receive input from privileged components (i.e. real input devices and designated assistance apps). I filed a bug with Apple about the ease of spoofing the Keychain authorisation and privilege elevation dialogs against OS X 10.2. Maybe by 10.11 they'll fix it...

      --
      I am TheRaven on Soylent News
    5. Re:The same basic approach works everywhere by drinkypoo · · Score: 1

      I filed a bug with Apple about the ease of spoofing the Keychain authorisation and privilege elevation dialogs against OS X 10.2. Maybe by 10.11 they'll fix it...

      Apple bug or security reports are like petitions on whitehouse.gov. If they notice them at all, it's to mock them. Sadly, the same is true of Android. Still no pinless pairing after how many years of people asking for it on the same two bug reports?

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    6. Re:The same basic approach works everywhere by benjymouse · · Score: 2

      It is isolated. In order to interact with it, a user must explicitly permit it by entering an admin's username and password.

      Sorry, but that is not isolation. If the prompt require a password rather than just an accept, the launching process can *still* control it remotely through Applescript - it would just not know what to put in the fields. That's not isolation. At best, it is a mitigating factor.

      Isolation would mean that any Applescript launched from the process was *barred* from interacting with the approval window.

      The vulnerability here is architectural: Windows can be remotely controlled. Ask yourself this: What good is an approval window, if the process can just remote control the approval itself?

      --
      Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
    7. Re:The same basic approach works everywhere by TheRaven64 · · Score: 1

      Do you? Can't the app just fork a child that runs the osascript tool (which should already have this permission) with the AppleScript?

      --
      I am TheRaven on Soylent News
    8. Re:The same basic approach works everywhere by Gunstick · · Score: 1

      in linux it's horribly easy.
      The keystore is not locked if your are logged in (i.e. screensaver is off).
      So a simple 3 lines script is enough to read all your passwords.
      This bug has been signalled multiple times.
      I never store my passwords in the keystore.

      --
      Atari rules... ermm... ruled.
    9. Re:The same basic approach works everywhere by Gunstick · · Score: 1

      on X11 most security dialogs are grabbing keyboard, which should disable any input except the mouse and keyboard from interacting with the window.
      So that makes it impossible to send keypresses to security dialogs.

      --
      Atari rules... ermm... ruled.
    10. Re:The same basic approach works everywhere by Rosyna · · Score: 1

      Uhm, the username and password entry is required before the controlling app even gets a chance to control anything, an admin has to approve the controlling.

      That is, the approval window (let's call it B) the article is talking about showing is not the approval window (that requires an admin's username and password, let's call it A) shown in order to allow one application to control another. A is shown before B is shown.

  9. Re:Gatekeeper by oh_my_080980980 · · Score: 1

    Exactly. It takes the fool to allow it to happen.

    On a bigger picture note - security needs to be more important for the end user. I think people tend to think that smart phones are less likely to be exploited than a PC and that bad things won't happen. People need to understand how to secure their phones and what behavior they should guard against.