New 'MACDefender' Malware Threat for Mac OS X

[munkery]

I didn't see clearly from the context if your "always" referred only to MacDefender or to any package installation, but thank you for the clarification. I don't know if you are completely correct, but I don't have proof otherwise.

It is possible that MACDefender would function properly with user installed browsers without password authentication if it was designed to do so, given that these browsers are not owned by system. But, this may not be the case depending on how it hooks into browsers.

Edit: The porn redirection may not require authentication on user installed browsers but MACDefender only targets Safari. It is possible that authentication to cause this behaviour is not even required for Safari.

I suspect that MACDefender asks for authentication to install in case the user is running a Standard account. MACDefender does not install any system level payloads, such as rootkits, that also require authentication to install.

 

[Member(TM)]

They can not modify applications owned by system in SL, such as the default apps (Safari, Mail, iTunes, etc) and apps installed via the Mac App Store.

But they can modify other applications that you may have installed and that you are relying on.

For what purpose if they can't collect valuable data such as passwords and sensitive web form data?

There are situations where they can. For example, if you have installed a third party web browser with drag and drop and you use it with the same admin user, it may be infected and start tracking your web form data.

They can not send spam from Mail.app if you have your email accounts securely configured.

If. Also, the malware may use other ways of sending spam that don't require Mail.app.

Backups via Time Machine and encryption using sparse bundle disk images will mitigate the impact of prank style attacks or data access.

True, but having to restore from your backups is always an inconvenience that is better to avoid if possible.

There is no motive in going after relatively difficult targets that yield very little valuable data when successfully exploited. Macs are difficult targets because privilege escalation is difficult so getting valuable data is less likely and the volume of data on any system is tiny compared to a server.

Security shouldn't rely too much on the lack of motive. There is no motive until someone thinks of one. Usually the scammer thinks of a motive before the potential victim does. That at this moment we can see no business reason for a malware maker to make a serious effort to attack Mac OS X systems, doesn't mean that someone won't find one.

I admit that my examples may not affect enough people to meet the critical mass needed to cause massive spreading. I don't disagree with your general idea that there's no need to panic. But overconfidence may also be dangerous. In my opinion the message "You don't have nothing to fear as long as you don't enter your admin password" is excessively overconfident.

 

[GGJstudios]

In my opinion the message "You don't have nothing to fear as long as you don't enter your admin password" is excessively overconfident.

That's not the message. The message has always been that a user should be careful to only install software that they intentionally acquired from a reputable source. That includes, among other things, not proceeding with an install package that they didn't initiate, not entering the admin password without being certain what is asking for it and why, and not clicking past warning messages without thinking. Think before you click. One can make up hypothetical scenarios all day long, but proof-of-concepts have no impact on the average user and, until the situation changes, no malware that exists in the wild will affect a Mac OS X system without the user's active permission and participation in installation.

 

[munkery]

But they can modify other applications that you may have installed and that you are relying on.

For what purpose? What apps?

There are situations where they can. For example, if you have installed a third party web browser with drag and drop and you use it with the same admin user, it may be infected and start tracking your web form data.

Nope, still need system level access. Browsers still run with user privileges in an admin account. No matter what app is the target, system level access is needed to hook into the kernel device drivers that implement the user space security mechanisms.

Also, the malware may use other ways of sending spam that don't require Mail.app.

Most email and IM clients rely on keychains. Just make sure you have the keychains set up correctly, then this is not an issue.

What other methods are available that don't rely on an active email account?

Spam is often sent from the email account itself after the password for the account has been collected. Collecting that password relies on system level access. Spam is not always sent directly from the computer. Changing the email accounts password usually corrects the issue.

True, but having to restore from your backups is always an inconvenience that is better to avoid if possible.

And, this is unavoidable in every OS. That is why backups are universally recommended.

Webkit2 will provide Safari and possibly other apps that use webkit, such as Mail, a sandbox similar to Chrome to further prevent the malicious access to user data. Webkit2 will be release soon along with the release of OS X Lion.

Security shouldn't rely too much on the lack of motive.

Profit is the motive. It is the lack of profitability not motivation that is the deterrent.

In my opinion the message "You don't have nothing to fear as long as you don't enter your admin password" is excessively overconfident.

No user is ever 100% safe from all the potential possibilities of malware. But, user knowledge can prevent most malware threats even before those threats are detected by antivirus software. Relying on antivirus software and firewalls without considering applying user knowledge is being overconfident.

 

[Member(TM)]

For what purpose? What apps?



Nope, need system level access. Still run with user privileges in an admin account. No matter what app is the target, system level access is needed to hook into the kernel device drivers that implement the user space security mechanisms.

There's no need for system level access in some cases. For example, the usual way of installing Firefox is just draging Firefox.app from the disk image to the Applications folder. If you are running as an admin user, you won't be promted for your password and the application will simply be copied with the unprivileged admin user as the owner. Any application that you run as that admin user will be able to modify the contents of the Firefox.app. I have tried it, it works and it's logical: if you have installed it as an unprivileged user, it's expected that you can also modify it as an unprivileged user. Of course if you don't like this behaviour you can change the ownership later, but probably most users won't do it.

Most email and IM clients rely on keychains. Just make sure you have keychains set up correctly, then this is not an issue.

What other methods are available that don't rely on an active email account?

Spam is usually sent from the email account itself after the password for the account has been collected. Collecting that password relies on system level access. It is not usually sent directly from the computer. Changing the email accounts password usually corrects the issue.

I'm not totally familiar with spam techniques, so the only way I can think of is if the admin user uses a third party mail application such as Thunderbird that was installed with a non privileged user and infected, similary to what I did with Firefox. (Not trying to deter people from using third party applications, but those are the examples I have thought of).

And, this is unavoidable in every OS. That is why backups are universally recommended.

Yes, I already agreed with that: keep backups, but make everything possible not to need them.

Profit is the motive. It is the lack of profitability not motivation that is the deterrent.

But again, the fact that I am unable to think how to make it profitable, doesn't mean that someone won't.

No user is ever 100% safe from all the potential possibilities of malware. But, user knowledge can prevent most malware threats even before those threats are detected by antivirus software. Relying on antivirus software and firewalls without considering applying user knowledge is being overconfident.

I agree. I simply think the same thing about relying on Unix security without applying user knowledge. And I don't disagree with most of what you said. The only point I am trying to make is that users are more vulnerable if they don't know what they are doing and they sometimes forget that some applications may be modified without needing system privileges.

 

[munkery]

There's no need for system level access in some cases....

No, you need system level access to hook into IOHIDSystem to bypass user space security mechanisms. Everything else you mentioned has nothing to do with bypassing user space security mechanisms.

so the only way I can think of is if the admin user uses a third party mail application such as Thunderbird that was installed with a non privileged user and infected

Does Thunderbird use keychain? If it does, set up the keychain properly. If it doesn't use keychain, then don't use Thunderbird.

The whole point of using the infected target's email account is to spread the malware to the user's contacts utilizing the user's email address to increase the success of social engineering ploys while trying to spread the malware.

If you just want to send out spam, make a bunch of email addresses to use to send spam. No need to infect computers just to send spam. I get spam emails that are not actually addressed to me all the time.

Botnets are used to send spam. But those botnets also install other payloads. Killing two birds with one stone.

But again, the fact that I am unable to think how to make it profitable, doesn't mean that someone won't.

Why bother going through all that effort to maybe profit from the user data on a Mac when you can plant rootkits in Windows XP systems with only a browser exploit and have that malware send you valuable sensitive data, such as bank login passwords and credit card data, collected by a system level keylogger?

Some keylogger malware use form grabbers to send the attacker only that valuable data so that the attacker doesn't have to search through the rest of the user's non-valuable keystrokes.

I simply think the same thing about relying on Unix security without applying user knowledge.

Obviously, that is true. The whole point of using DAC by default is to make it possible that applying user knowledge is actually pragmatically useful.

Trying to apply user knowledge when simply visiting a website easily provides system level access, as in XP admin accounts, is not possible.

The only point I am trying to make is that users are more vulnerable if they don't know what they are doing and they sometimes forget that some applications may be modified without needing system privileges.

Modifying those apps does not provide system level access. So, no rootkit install. No keylogger that can log passwords and sensitive web form data install. No form grabber install. No to anything that makes profitability worth the effort.

 

[Member(TM)]

No, you need system level access to hook into IOHIDSystem to bypass user space security mechanisms.

You don't need to bypass user space security mechanisms to modify an application in the scenario I presented, which is the common way to install Firefox and many other third party applications. All the contents of Firefox.app are writeable by the unprivileged user who installed it, so a possible Trojan doesn't need your admin password to modify it.

Once the application has been modified you don't need to hook into IOHIDSystem to intercept user input inside Firefox.

Does Thunderbird use keychain? If it does, set up the keychain properly. If it doesn't use keychain, then don't use Thunderbird.

Again, if Thunderbird has been modified by a malicious program, how the keychain is set up is irrelevant.

Obviously, that is true. The whole point of using DAC by default is to make it possible that applying user knowledge is actually pragmatically useful.

That's the point I was trying to make. That users should know what risks they are taking according to their actions, and in particular that there is a certain amount of damage that may be caused even if you don't enter your admin password. Whether the potential damages don't affect the whole system and whether Mac OS X users are improbable targets doesn't affect my point. That every problem I exposed may be prevented applying user knowledge is exactly my point.

 

[munkery]

You don't need to bypass user space security mechanisms to modify an application in the scenario I presented, which is the common way to install Firefox and many other third party applications. All the contents of Firefox.app are writeable by the unprivileged user who installed it, so a possible Trojan doesn't need your admin password to modify it.

This type of modification does not bypass user space security mechanisms. These security features function in kernel space which requires system level privileges to modify.

Once the application has been modified you don't need to hook into IOHIDSystem to intercept user input inside Firefox.

Mac OS X implements two user space security mechanisms that prevent keyloggers and other malware from logging protected passwords and sensitive webform data. The first security mechanism is called EnableSecureEventInput which prevents keyboard events related to security sensitive logins being logged after the input exits IOHIDSystem. The other security mechanism is called NSSecureTextField which prevents password from being viewed or captured in the user interface by form grabbers.

Keyloggers installed in kernel space are able to log these protected passwords. Looking at the source code for logkext shows it interacts with IOHIKeyboard located in the IOHIDSystem bundle to log keyboard events in kernel space. To locate these items in finder, do an advanced search in Finder for IOHIDFamily and search inside the package contents for IOHIDSystem. Kernel space keyloggers require password authentication to install. These kernel device drivers are protected by the discretionary access controls of OS X.

Again, if Thunderbird has been modified by a malicious program, how the keychain is set up is irrelevant.

The account login credentials are stored in keychain. If you keep the keychain containing those credentials locked, then those credentials can't be used without the user entering that keychain's password to allow access to those credentials. The function of keychain is completely indepentent of a third party app being modified.

Also, there is no real good need to turn a machine into a spam bot unless other malware is installed in the system as well. There are easier methods to send spam anonymously without hijacking email accounts using malware.

That's the point I was trying to make. That users should know what risks they are taking according to their actions, and in particular that there is a certain amount of damage that may be caused even if you don't enter your admin password.

The risks and damages that can be done are not worth the effort to produce malware that capitalizes via those methods. These risks are a reality of every OS. There will never be a perfect mitigation against those types of damages in any OS.

Whether the potential damages don't affect the whole system and whether Mac OS X users are improbable targets doesn't affect my point.

But, this does impact the probability of malware being produced that targets OS X.

That every problem I exposed may be prevented applying user knowledge is exactly my point.

That sure didn't seem like your intent when you started posting in this thread.

 

[Member(TM)]

This type of modification does not bypass user space security mechanisms. These security features function in kernel space which requires system level privileges to modify.



Mac OS X implements two user space security mechanisms that prevent keyloggers and other malware from logging protected passwords and sensitive webform data. The first security mechanism is called EnableSecureEventInput which prevents keyboard events related to security sensitive logins being logged after the input exits IOHIDSystem. The other security mechanism is called NSSecureTextField which prevents password from being viewed or captured in the user interface by form grabbers.

Those security mechanisms only protect the data from third parties, but don't protect it from the trusted application where you are entering the data. The malicious code is now in the trusted application. Now it's the trusted application itself the one logging key events. Those mechanisms can't prevent this nor can control where the application sends the data.

Keyloggers installed in kernel space are able to log these protected passwords. Looking at the source code for logkext shows it interacts with IOHIKeyboard located in the IOHIDSystem bundle to log keyboard events in kernel space. To locate these items in finder, do an advanced search in Finder for IOHIDFamily and search inside the package contents for IOHIDSystem. Kernel space keyloggers require password authentication to install. These kernel device drivers are protected by the discretionary access controls of OS X.

For the same reason as before, the malware doesn't need kernel space keyloggers. The compromised trusted application is the keylogger.

But, this does impact the probability of malware being produced that targets OS X.

Agreed. But it does no harm in my opinion trying to reduce the probability even more, as long as your decisions are well informed.

That sure didn't seem like your intent when you started posting in this thread.

Then I didn't explain myself well.

 

[munkery]

Find an example of a keylogger or form grabber that can log protected password without requiring password authentication to install? They do not exist.

Edit: I do not believe you are referring to keyloggers or form grabbers that rely on vulnerabilities within the OS.

What you are referring to is XSS. This can be done in the browser via web injection but it is dependent on the web app, with which the user's browser is interacting, having a vulnerability.

The vulnerability is in the web app that is hosted on the server and not in the browser on the user's machine. The flaw in the web app allows the attacker to abuse the interaction between the client (user's browser) and the server (web app).

This can be done by tricking users to follow a link that has scripts embedded in the URL. Browsers include systems to detect scripts injected into URLs but these systems are not 100% effective. Safe browsing practices can prevent this type of exploitation.

This only works in web apps that have a vulnerability.

Second Edit: Despite web app vulnerabilities not being uncommon, web app vulnerabilities in security sensitive websites, such as online bank logins, are rare given the sensitive nature of the logins.

Because of this lack of vulnerabilities in bank login web apps, web injection is used by malware to modify the web page logins to collect data above and beyond that typically asked for on the bank logins web page to further increase the potential gain from the crime.

Because no web app vulnerability is present to perform XSS, the collection of data from these logins still relies on system level keyloggers to bypass user space security mechanisms to log the protected data entered into the online banking logins. This is true for every browser, including those that are user installed.

The installation of malware that includes system level keyloggers can be prevented by being careful in relation to password authentication.

 

[hoodgyno]

Go to youtube and view a video posted by macmostvideo about the Macdfender malware program, then breathe easy.

 

[djshack]

Go to youtube and view a video posted by macmostvideo about the Macdfender malware program, then breathe easy.

Just shows how ignorant someone must be to install this "trojan."

 

[AidenShaw]

Just shows how ignorant someone must be to install this "trojan."

But, judging by the other story about the Apple call volume on this, it shows how ignorant many Apple users are.

And, why anti-malware software that warns the user is a good idea.

 

[munkery]

But, judging by the other story about the Apple call volume on this, it shows how ignorant many Apple users are.

And, why anti-malware software that warns the user is a good idea.

As long as you pick the right AV software, it definitely can't hurt!

https://www.microsoft.com/technet/security/advisory/2491888.mspx

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0037

EDIT: Despite the links that are provided in this post, I do recommend Microsoft Security Essentials to Windows users. All antivirus software that runs with elevated privileges has privilege escalation vulnerabilities every once and a while. MSE has a better track record than most commercial AV software in this regard.

 

[MacmancUK]

Avalanchers.com RSS feed, some webpages download the mac malware programme, my iMac uses camino and every time a download starts, it tells me, so I stop it.

Since I stopped RSS'ing Avalanchers.com, and instead RRS'd the individual feeds, I have not had a single download of "mac malware".

MacDefender, or otherwise

I have told them so.

 

[Member(TM)]

Find an example of a keylogger or form grabber that can log protected password without requiring password authentication to install? They do not exist.

I haven't claimed that they exist though. What I have claimed is that any application can obviously log any text typed inside its own windows. If I'm a malicious developer, I can develop a web browser that resends to me any form data, including passwords, that my users submit to any website. Unless the user has installed an outbound firewall, the only other way to prevent this is not installing my malicious browser.

Instead of distributing a web browser, I may prefer to write a different kind of Trojan that simply modifies a previously installed legitimate web browser. If that legitimate web browser was installed without admin authentication, then it can be modified without admin authentication. My modification may make it resend to me any form data exactly the same as the previous case.

Please note that I'm not talking about the practicality or probability of such attack, only of its technical feasibility. System security doesn't (nor shouldn't) prevent a user from modifying files they own, including applications.

Edit: I do not believe you are referring to keyloggers or form grabbers that rely on vulnerabilities within the OS.

Exactly. I have tried to be clear, apparently without much success, that I'm not talking about vulnerabilities within the OS.

What you are referring to is XSS. This can be done in the browser via web injection but it is dependent on the web app, with which the user's browser is interacting, having a vulnerability.

No. It's much simpler than that. What I'm referring to is users who overwrite files they own. That's totally normal behaviour, and it isn't wrong in itself. I'm not trying to make a big deal of it, but it seems some people were centering the debate on whether malware requires the admin password or not. Malicious applications may do damage without the need of an admin password. Limited damage, it's true, but depending on the particular circumstances of each user, it may be too much damage.

What I have said may perfectly involve an invulnerable OS, an invulnerable web browser, an invulnerable web site, a Trojan horse... and a deceived user.

 

[JAT]

But it's beside my original point that obscurity is most definitely a factor in why the Mac has less malware overall than Windows machines.

The problem with this argument is using actual percentages of Mac vs Win. And then comparing actual percents from when MacOS7-9 were current. The market share percents were similar back then, while the malware numbers are not.

 

[munkery]

I haven't claimed that they exist though. What I have claimed is that any application can obviously log any text typed inside its own windows.

The specifics of masked data is not sent to the UI. The UI is told that a character has been entered to render the masking element but the specifics of the character do not reach the window.

If I'm a malicious developer, I can develop a web browser that resends to me any form data, including passwords, that my users submit to any website. Unless the user has installed an outbound firewall, the only other way to prevent this is not installing my malicious browser.

No, see my response above and factor in the security occurring between the interaction of the client (browser) and the server (website). Collection of the sensitive data requires abusing that interaction. If the website requires an encrypted connection, the attacker would only receive encrypted data. All website logins that relate to financial transactions use encrypted connections.

Instead of distributing a web browser, I may prefer to write a different kind of Trojan that simply modifies a previously installed legitimate web browser. If that legitimate web browser was installed without admin authentication, then it can be modified without admin authentication. My modification may make it resend to me any form data exactly the same as the previous case.

Again, this depends on the client/server interaction as stated above. Again, then the following applies:

Despite web app vulnerabilities not being uncommon, web app vulnerabilities in security sensitive websites, such as online bank logins, are rare given the sensitive nature of the logins.

Because of this lack of vulnerabilities in bank login web apps, web injection is used by malware to modify the web page logins to collect data above and beyond that typically asked for on the bank logins web page to further increase the potential gain from the crime.

Because no web app vulnerability is present to perform XSS, the collection of data from these logins still relies on system level keyloggers to bypass user space security mechanisms to log the protected data entered into the online banking logins. This is true for every browser, including those that are user installed.

Please note that I'm not talking about the practicality or probability of such attack, only of its technical feasibility. System security doesn't (nor shouldn't) prevent a user from modifying files they own, including applications.

This is not technically feasible.

No. It's much simpler than that. What I'm referring to is users who overwrite files they own. That's totally normal behaviour, and it isn't wrong in itself. I'm not trying to make a big deal of it, but it seems some people were centering the debate on whether malware requires the admin password or not. Malicious applications may do damage without the need of an admin password. Limited damage, it's true, but depending on the particular circumstances of each user, it may be too much damage.

An admin password is required to bypass user space security mechanisms to log protected password for security sensitive logins.

 

[Member(TM)]

The specifics of masked data is not sent to the UI. The UI is told that a character has been entered to render the masking element but the specifics of the character do not reach the window.



No, see my response above and factor in the security occurring between the interaction of the client (browser) and the server (website). Collection of the sensitive data requires abusing that interaction. If the website requires an encrypted connection, the attacker would only receive encrypted data. All website logins that relate to financial transactions use encrypted connections.

None of your arguments apply to my example. If the user is trusting my web browser, then I don't need anything else. How do you think that a client communicates with a server? Who does construct the HTTP request that is sent to the server? My malicious web browser does from the raw data the user entered. Who does encrypt the data? My malicious web browser does from the unencrypted data the user entered. What else can my malicious web browser do with the data? Anything I want. I don't need to unencrypt the data because I'm the one who encrypted it.

Anyone who has developed a web browser or an analogous network application knows that what I'm saying is correct. If you are not convinced by my arguments, I don't see other way to prove it than publishing a malicious web browser, which would be illegal. So I guess we'll have just to disagree on this subject.

 

[munkery]

None of your arguments apply to my example. If the user is trusting my web browser, then I don't need anything else. How do you think that a client communicates with a server? Who does construct the HTTP request that is sent to the server? My malicious web browser does from the raw data the user entered.

HTTP facilitates communication between the client and server via a request/response paradigm. Much of how data related to those requests is handled is defined by other elements within the OS, such as the Secure Transport API for SSL encrypted connections.

Who does encrypt the data? My malicious web browser does from the unencrypted data the user entered. What else can my malicious web browser do with the data? Anything I want. I don't need to unencrypt the data because I'm the one who encrypted it.

The SSL certificate of the website defines the encryption of the data. Using the info from the certificate, the Secure Transport API built in to OS X encrypts the data following the parameters provided by the SSL certificate. SSL functions on the TCP/IP layer while the browser functions at the application layer. The browser uses the API but it can not manipulate its function.

Anyone who has developed a web browser or an analogous network application knows that what I'm saying is correct. If you are not convinced by my arguments, I don't see other way to prove it than publishing a malicious web browser, which would be illegal. So I guess we'll have just to disagree on this subject.

It is not illegal to produce a proof-of-concept. I am pretty sure that such a PoC would exist if it was possible on any OS.

Applications can be owned by the user on all OSs. Chrome is owned by the user in Windows.

So, a browser exploit could be used to install a spoofed version of IE, nuke the registry entry for legit IE (registry entry corruption occurs in wild in Windows -> FakePAV), hijack the shortcuts to IE (user has write privileges concerning shortcuts), and then collect the users data when the spoofed browser is used?

If it was that easy, spoofed malware versions of IE would be all over the place.

 

[maclaptop]

It will be very interesting to see how Apple handles this issue.

How long to issue a fix, which is what the public expects?

How long before the story goes away?

 

[munkery]

It will be very interesting to see how Apple handles this issue.

https://www.macrumors.com/2011/05/24/apple-to-update-mac-os-x-to-remove-mac-defender-malware/

http://support.apple.com/kb/HT4650

How long to issue a fix, which is what the public expects?

Using the same type of attack targeting Windows as a model for a timeline, I would say that it will not be fixed because rogue AV software doesn't use any exploits to function.

http://www.microsoft.com/security/sir/keyfindings/default.aspx#section_4_4

How long before the story goes away?

Only those that want to perceive this as a story see it that way. Interestingly, nobody seems to give a load to the same degree about similar malware that targets Windows. Seems strange?

 

[MagnusVonMagnum]

Originally Posted by maclaptop
How long before the story goes away?

As soon as you hit unsubscribe....

 

[Member(TM)]

It is not illegal to produce a proof-of-concept. I am pretty sure that such a PoC would exist if it was possible on any OS.

A proof of concept of my claim is not illegal, but I'm under the impression that you won't be satisfied just with that. What I'm claiming is so obvious that what I have already said should have convinced you, and that obviousness is the reason why no one bothers to provide such proof of concept.

I can only think that you are misunderstanding what I'm claiming, and possibly I'm also misunderstanding what you're claiming, so before I bother to provide a proof of concept, let's first check if we are understanding each other and maybe agree on what proof of concept should be needed to solve the question. Let's try to be as concise and unambiguous as possible.


1.- CLAIMS

My claim: a Mac OS X application with keyboard focus running in user space is able to read data entered by the user and it can send those data to a web server chosen by the application developer.

Your claim: a Mac OS X application with keyboard focus running in user space is unable to read data entered by the user and it cannot send those data to a web server chosen by the application developer.


2.- PROOF OF CONCEPT

An application with several editable text fields and a submit button. When the user presses the submit button, the application will send the data to the developer's web server, which will store them into a database.


3.- VERIFICATION

I'll keep a downloadable application package and server side support for a limited time, and I will post on this forum the data submitted to the server by testers.

-----------------------

What do you think? Have I understood your claim? Do you find the stated proof of concept valid for such claim? If not, what are you exactly claiming and what kind of proof would you consider valid?

 

[munkery]

1.- CLAIMS

My claim: a Mac OS X application with keyboard focus running in user space is able to read data entered by the user and it can send those data to a web server chosen by the application developer.

Your claim: a Mac OS X application with keyboard focus running in user space is unable to read data entered by the user and it cannot send those data to a web server chosen by the application developer.

No. My Claims:

1) a Mac OS X application without keyboard focus that is installable without password authentication is unable to read data protected by user space security mechanisms that are entered in another application. Not all data is protected; protected data includes login credentials for websites that establish encrypted connections using digital certificates, such as online banking login credentials.

2) a malicious web browser with keyboard focus that is able to establish and login to encrypted logins that is also installable without password authentication is unable to bypass the user space security mechanisms to log protected keystrokes and send the protected data (defined as login credentials to websites using encrypted connections) to the attacker in a state that it is readable to the attacker.

3) a legitimate web browser (such as Firefox) that is owned by the user can not be modified to achieve the same effect as described in #2.

2.- PROOF OF CONCEPT

An application with several editable text fields and a submit button. When the user presses the submit button, the application will send the data to the developer's web server, which will store them into a database.

The proof-of-concept must be a web browser fitting the description of either #2 or #3 that I can use to navigate to an encrypted login, that will make the ssl connection with that login page, and then send login credentials to a destination other than the webpage login's web server in a form that the attacker (you) is able to read.

This is what you are suggesting is possible to make.

3.- VERIFICATION

I'll keep a downloadable application package and server side support for a limited time, and I will post on this forum the data submitted to the server by testers.

I will set up a login for a website that uses digital certificate to create an encrypted connection. Exposure of these credentials will not matter to me as I will use an anonymous email to generate the account.

I will post the username and url for the account in this thread after I receive your malicious browser to start testing if it works.

You post my login credentials for that website after you receive them via your maliciously crafted web browser.