Slashdot Mirror
Safari Privacy Bug May Be Leaking Your Data
richi writes "If you use Safari, your browser may be leaking your private information to any website you visit. Jeremiah Grossman, the CTO of WhiteHat Security, has discovered some Very Bad News. I have some analysis and other reactions over at my Computerworld blog. The potential for spam and phishing is huge. A determined attacker might even be able to steal previously-entered customer data." In short, autofill for Web forms is enabled by default in Safari 4 / 5 (and remotely exploitable), and the data that this feature has access to includes the user's local address book — even if the information has never been entered into a Web form.
It seems that the bug is due to Safari allowing keyboard events to be generated from Javascript, so a malicious script can pretend to interact as if it were the user, whereas Firefox doesn't get fooled.
--
The Founder Conference is coming August 17
This reminds me of Windows. It's impossible to override certain key combinations like CTRL+ALT+DELETE.
It's kind of obvious: you don't let a program ever, imitate the user in the same context. Web browsers should never have been able to create windows 'outside' of the rendering area to boot (unless full screen)... browsers should never have been able to 'see' what the user sees in regard to links...Internet explorer showing contents of C:\...and so on...
Slashdot needs Geekcode | Can anyone recommend any good SCIFI? My tastes: Foundation, Startide Rising, CITY, Ringworld,
It could be that more of the vulnerabilities are being found in open source browsers than in closed source browsers. In other words, closed source browsers may have many more undiscovered security problems. IE still has security vulnerabilities they're not fixing, both ones that are publicly known and ones that only Microsoft and a few others know about. Chrome and Firefox have no publicly known security vulnerabilities today.
What a fool believes, he sees, no wise man has the power to reason away.
Would that have been before or after Eric Schmidt resigned Apple's board and they became sworn enemies? He didn't get mad because Steve started stalking him, did he?
Oh well, I'll hit submit in Safari now...
"If you use Safari,..."
Phew. That takes care of everyone.
Even if you've never used the Address Book app this information could be in there. In the OS X first-launch setup dialog it asks for your real name, and that gets automatically inserted into the address book. I'd wager that most people who use Macs have done this, so their real names are accessible to any website using this technique.
Additionally, though this is less likely, if you fill out the registration form during setup I believe that information also goes into the address book, so there's your home address and email too.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
Browsers are about the most complex piece of software you will find anywhere. Think about all they can do. They have a not just one page rendering algorithm, several different types. Different modes mean different things, and W3 lists over 20 different modes.
Then they have the networking part, that communicates to servers, opening several sockets at a time and coordinating their retrieval. And they have to be able to do it with HTTP1.0 or HTTP2.0. And they have to be able to handle weird HTTP things, like password authentication.
After that, they have to be able to parse at least three different image types (and image parsing libraries are a great place to look for vulnerabilities because they are complex and the data is hard to validate). And they have to be able to interact with the OS in some way to allow movie and audio playing. And flash. And Java Applets. And any other weird plugin.
Then add to it a complex, object oriented, interpreted language (as if the several versions of HTML weren't bad enough), and the fact that the entire page has to be dynamic. Quickly dynamic: people want to do animations with this stuff, it has to happen in milliseconds.
And a spell checker. Oh, and it has to be able to interact with and recognize tons of different character encodings. In short, if I had a choice between writing a kernel and guaranteeing that it was vulnerability-free, and writing a browser and guaranteeing it was vulnerability-free, I would take the kernel any day. It's a significantly easier piece of software.
So there are still bugs in IE too, don't worry.
Qxe4
Umm... WHAT? Sorry to burst your conceit bubble there, Sparky, but... "Many eyes make bugs shallow" does not apply to Safari, because Safari is not open source software.
Webkit (the open source rendering engine that Safari uses) is not vulnerable. Chrome and Chromium (also built on Webkit) are also not vulnerable. Webkit is fine, at least in regards to this vulnerability.
Safari (the closed-source browser built on Webkit) is vulnerable.
This is a closed-source software bug that has been reported to the vendor.
I don't disagree that all software has bugs. That's going to be true. But this is an example of the opposite.
"This post contains words, known to the State of California to cause thought. Wash brain thoroughly after reading."
Actually, this is a perfect example of it.
The vulnerability is in closed-source software, because Safari is closed-source. The vulnerability does not exist in Webkit (the open source component of Safari), so no one but Apple can fix this issue.
The issue was discovered almost by accident. Safari allows Javascript to emulate keypresses (which is almost inconceivably stupid).
If any respectable open source team member had seen Javascript events being passed to the keyboard buffer, he or she would have screamed blue bloody murder and it would have become a priority one bug faster than you can say "the developer who wrote that shit has just lost code submission privileges on this project".
"This post contains words, known to the State of California to cause thought. Wash brain thoroughly after reading."
In short, if I had a choice between writing a kernel and guaranteeing that it was vulnerability-free, and writing a browser and guaranteeing it was vulnerability-free, I would take the kernel any day. It's a significantly easier piece of software.
The kernel (let's use Linux as an example) is significantly higher quality, not because it is a simpler piece of code but because it is written by people who aren't morons and actually care about robustness. A web browser has a lot of spec cruft to contend with, but that's peanuts -- a kernel has to contend with anything that could possibly occur on the machine, in any order, simultaneously or not, by any user, using any device, with any amount of memory, any number of CPUs, and any unknown modifications, modules, or other tweaks that might be in place. Comparing the two types of software is insane.
Just don't hold it like that.
and the data that this feature has access to includes the user's local address book
The only card that can be read is the "Me" card, not the whole address book.
If any respectable open source team member had seen Javascript events being passed to the keyboard buffer, he or she would have screamed blue bloody murder and it would have become a priority one bug faster than you can say "the developer who wrote that shit has just lost code submission privileges on this project".
I'm not buying your assertion that open source developers are more attentive or more dedicated than non-open source developers. What is the rationale for that?
Other than defining the QA process to be whatever you want and being your own QA team, what advantages does a project being open source confer in this regard? Some outsider can swoop in and patch your critical security vulnerabilities for you, with tests, and no new bugs? Your users can fix bugs on their own, maintaining private one-off branches?
Not to dig on open source or anything, but I think it's usefulness is being pushed a BIT too far sometimes. There are certainly places it shines, but this is not one of them.
I don't disagree with your main point that web browsers are very complex. However, the above quote is pure hyperbole. There are many types of software that make web browsers look like child's play. Among them, I would say, are avionics software, flight software for satellites, etc. Those are just a couple examples - I'm sure there are quite a few others.
the Q/A being in the open anyone can go file and read through the bug reports, and if anyone actually didn't assign such a bug as priority one, then the whole project would be ridiculed, probably here and in many other places.
Your post [about F/OSS software being safer due to the "many eyes" phenomenon] would make sense if the majority of the work done on Webkit and Firefox was not done by professionals.
I don't think any definition I've seen of Free/Open Software includes anything at all about the professional status of the programmers.
In fact, much of the work on the most popular F/OSS packages is done by "professional" programmers. This is widely understood as a way to improve your public image and résumé, since it allows you to get involved with new things that an employer wouldn't permit. Most employers don't like people working on something that they've never done before, so if you want experience with something new, you usually have to work on it in your copious spare time, i.e., as a Free Software project. And, of course, you want it to also be Open Source, so that people can read your good work and be impressed.
It's also common for the more enlightened managers to approve of employees getting involved in F/OSS work, for the same reasons, and to give the company more credibility among software developers.
But it's common for the corporate world to disparage Free/Open software developers as unpaid professionals. It's pure ideological PR, though, with little basis in reality. (Reality is always a lot messier than anyone's ideology. ;-)
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
The standard event model allows javascript to trigger events such as keystrokes.
Its easy to see why a browser obsessed with speed would just forward the API call to the internal event model. I can totally see the appeal and instinctive reaction to a situation like this; its clean, fast and simple coding - security is not often a big goal when you are initially just trying to get something working; even so, this could get missed by multiple eyes... Plus this is not part of webkit - its bridging the engine to the GUI; which is an unusual situation compared to the bulk of code - all the hard work is in the engine this just ties that to a GUI, quite likely there is a separation between working groups - obviously there is one since the engine is open source and the GUI is not. Their job is to bridge and probably do not get the level of attention as other aspects of the program.
I'm not letting them off the hook, this should have be caught within 1 version or during a security audit if there was one... and if there was:
1) was the attention given to the engine only?
2) do these people work on the code so they get tied up fixing bugs instead of just logging all the ones they uncover? (a lack of specialization)
Democracy Now! - uncensored, anti-establishment news
Umm... WHAT? Sorry to burst your conceit bubble there, Sparky, but... "Many eyes make bugs shallow" does not apply to Safari, because Safari is not open source software.
Webkit (the open source rendering engine that Safari uses) is not vulnerable. Chrome and Chromium (also built on Webkit) are also not vulnerable.
Well, yes and no.
Jeremiah Grossman said...
@Anonymous, Tom: I believe this may be a WebKit issue and not just Safari. While it is difficult to confirm now, I suspect this technique did in fact affect Chrome. Had some discussions with Google a while back surrounding this topic and recall them finding/fixing something, but I don't really get all the details straight. Will have to find an older Chrome version somewhere to confirm...
@anonymous: this hack may have worked on Chrome at one time, but no longer. Trying to confirm, but difficult to get old OS X copies. :)
Lars T.
To the guy who modded me down from perfect to terrible Karma - Apple haters still suck
I'm not buying your assertion that open source developers are more attentive or more dedicated than non-open source developers.
It may even go the other way, it may foster complacency. A programmer working on an open source project may be more likely to assume that someone else has already looked at the code and therefore that they don't need to do it themselves. In an organization there would be someone who's specific job is to audit everything, but if that's left as a community task with no one person taking responsibility for it then it might breed complacent developers.
Obviously this is pure speculation.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
If you are going to shove words into my post, shove the words I was replying to into my post:
Could it be that the job is simply to complex for most non-professionals and that the open source model has reached the end of it's useful life?
Nerd rage is the funniest rage.
After that, they have to be able to parse at least three different image types (and image parsing libraries are a great place to look for vulnerabilities because they are complex and the data is hard to validate). And they have to be able to interact with the OS in some way to allow movie and audio playing. And flash. And Java Applets. And any other weird plugin.
All of these are certainly complex requirements which could understandably lead to bugs.
What it is not acceptable is for bugs in a data processing algorithm - say, image rendering - to even be able to lead to vulnerabilities.
There is no logical need, for example, for a JPEG parser to even conceivably trigger arbitrary code execution if the programmer makes an off-by-one error in an array subscript. It's simply irrelevant to the task of that code. It should be literally impossible to make a mistake in such code in such a way as to trigger code execution.
Because Internet programming is so complex that if vulnerabilities are not made impossible, they are a certainty, and a certain vulnerability times the size of the Internet mean even the smallest mistake is no longer tolerable. Humans simply can't work with that degree of precision, nor should they ever need to. This is exactly what we built computers for: to take over the repetitive drudge work which we can't do without error. So while a programmer can be assured to make errors, it's the job of the language to make it impossible for errors in data manipulation to lead to logically-unrelated weirdnesses like code execution.
Surely this isn't rocket Turing Machine science. We don't have to solve the halting problem to get rid of buffer overflows, do we?
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
It could be because between open source and non-open source developers, only one group has a boss to hate.
Freedom to do the best job you can and the sheer desire to create a product that's good enough that you would use is a very strong motivating factor.
I'm not saying this is necessarily the "rationale" you asked for, but maybe. Maybe the open source developers didn't have to waste their time going to "team building" workshops, or Monday breakfast meetings or have to keep their mouth shut while their boss screws something up or takes credit for the developers' work.
Not that open source shops are utopias, but I think it's possible that they are more dedicated than their colleagues at Microsoft or Apple.
Wait a minute now. We're talking about four browsers. The ones from Apple and Microsoft have security vulnerabilities and the ones from Google and Mozilla do not. Is it just coincidence?
You are welcome on my lawn.
and they are: Alan Jones, 9112 Tarquin Drive Luton New Hampshire, Bday Nov 3, 1970, SSN# 867-53-0909...
Arthur J. Smith, 30612 Jethro Lane, Biscuitbarrelville Connecticut,
James Walker, 26318 Adrian Telescope Road, Harpenden Maine
"Waste not one watt!" - CZ
If any respectable open source team member had seen Javascript events being passed to the keyboard buffer, he or she would have screamed blue bloody murder and it would have become a priority one bug faster than you can say "the developer who wrote that shit has just lost code submission privileges on this project".
Given that most Safari developers working for Apple are very respectable Open Source team members that contribute heavily to WebKit, I will have to say that your assertion is simply not true.
Really? Because there is discussion between developers (not just fanboys like yourself) about it existing and being fixed in chome because its likely a webkit issue, not Safari.
Of course, I don't know that for a fact because its too soon to tell, but that didn't stop you from spouting some ignorant bullshit so why should it stop me?
Its a bug in the javascript and dom code ... which ... guess where that code comes from ... Its not like Safari does it different than every other WebKit based browser.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
I've written my own kernels for microcontrollers and I've done a fair amount of embedding Gecko and now Webkit.
Embedding Gecko pretty much means you have to become a browser dev because mozilla is full of idiots but I digress.
I would, without any doubt in my mind, write kernel code over browser code.
Kernel code is freaking EASY compared to a browser. I'm more confident in fake 'memory protection' I can create without an MMU than I am of anything in a browser, and I know the fake memory protection is trivial to blow right past.
Hardware is really easy to deal with because there aren't 300 layers inbetween you and the real hardware. Way too much redirection and other code in a browser, not only do you have the browser code but you also have all the code under it that makes it useful, including the kernel.
Give me a SGI onyx with 64 processors and tell me to make a kernel and I'll do it.
Tell me to write a rendering engine for a markup language and my first question will be 'whats the pay rate and whats the signing bonus for even considering taking the project'.
Browser programming fucking sucks.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
I'm sorry, have you actually USED any OSS software?
Yes, thats true for a few things, but the 'quality' and 'movtivation' of OSS devs is just as shitty as closed source devs. For ever good OSS project there are roughly 1000 shitty ones, and the same is true for closed source software.
The people who write open source software are VERY OFTEN the EXACT SAME ONES writing closed source software. Most of the time its because one is so they can eat and the other is so they can relax and enjoy themselves.
So instead of having real motivation like 'fix the fucking bugs or your fired and don't get paid' or we have OSS motivation 'I'll feel special if I fix a bug!' ... And you think thats going to make OSS safer? Let me tell you how developers work. They write some code that they are proud off and think is bug free, and then ... someone finds and exploits thier pretty code because only about 1 out of 10,000 even care about finding bugs rather than pushing out new features, and only one in 10k of those actually have the skills to examine code and applications to find bugs, even fewer still have the ability to figure out ways around security mechanisms.
Wait, what? Are you blind or just born yesterday and don't have any clue wtf you're talking about? Let me quote what the person who found the bug said on the page linked since no one bothers to read it ...
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
"Internet Explorer, Firefox, Chrome, and Safari browsers are susceptible to attacks that allow webmasters to glean highly sensitive information about the people visiting their sites, including their full names, email addresses, location, and even stored passwords, a security researcher says."
although the exploits are different for each browser. Read more here
It certainly is possible to override CTRL-ALT-DELETE.
Even something as basic as an Adobe 'Macromedia' Director projector can trap it using something like Meliorasoft's Keyboard Control Xtra"