Multiple Security Holes In Ruby 1.8, 1.9 148
ruphus13 notes a six-pack of serious vulnerabilities discovered in Ruby by a member of Apple's security team, Drew Yao. Patches are linked from the ruby-lang.org advisory. "With the following vulnerabilities, an attacker can lead to denial of service condition or execute arbitrary code... These vulnerabilities are likely to crop up in just about any average ruby web application. And by 'crop up' I mean 'crop up exploitable from trivial user-specified parameters.' It's not hard to begin imagining cases where Ruby/Rails programmers use code similar to the samples above to routinely handle user input."
Derailed (Score:2, Funny)
Re: (Score:3, Informative)
Re: (Score:2)
Re: (Score:3, Insightful)
Was there not a recent demonstration on a 'blended threat' based on the safari bug that would execute code next time IE ran, also I beleive there is another similar method for firefox 2/3.
No, there still is a bug in IE that will run any properly named DLL on the Desktop, whether it is downloaded with the "Carpet Bomb", or by hand with any browser, download tool (incl. FTP or P2P), or moved there, or put there by fairies. And there is also a bug in Firefox that allows somebody to "steal files", which has probably to do with a certain kind of file being in its Download Folder (by default the Desktop) - again, no matter how it got there. These are bugs that need to be fixed.
Goes to show ... (Score:2, Insightful)
This, IMHO, goes to show that Ruby isn't any better than the other Open Source interpreted languages. Despite what the Ruby fanboys allways claim, it is actually far less mature then, let's say, Python or PHP.
A matured, tested and established mod_ruby, unicode and a few years more in the field is what Ruby needs before I take a look at it.
My 2 cents.
Re: (Score:3, Insightful)
Keep in mind that ruby and PHP are essentially contemporaries - they've both been in real use for over a decade. By most measures, one would think of them as being "mature" technologies, and yet we still see bugs like this crop up in both languages. I think it just goes to show - while selecting a "mature" technology has its advantages, it will not make you immune to problems.
For what it's worth, this appears to be a flaw in the official ruby interpreter. That's a big deal, of course, but just so you k
Re: (Score:3, Informative)
I'd interpret the same facts the other way around. A decade isn't very long for a programming language to mature. Ruby and PHP hav
Re: (Score:2)
``You could say it's my own darn fault for choosing a beta version of the language, but with a more mature language I wouldn't have had to make a choice like that between features and stability.''
I agree with everything you say, but this part is slightly off. The only way not to have to make that choice is if you don't have it. Maturity of the language (or the implementation, in this case) doesn't factor into it, because the code for new features will invariably be less mature than older code, regardless of
Re: (Score:2)
You can also use a still more mature language such as Tcl [www.tcl.tk]. Tcl has to my knowledge had next to no security vulnerabilities in recent years and has a very high quality codebase.
Re:Goes to show ... (Score:4, Insightful)
And it never claimed to be. I don't know anyone who uses Ruby because it's more secure. Everyone I know who uses Ruby does so because of the beautiful syntax, pervasive OO, and other things that make it nicer to program in.
And again, it's not the security. I'm willing to risk having to patch my interpreter like this once in awhile, if it means I'm able to
Keep in mind, this vulnerability is so far only a DoS, and won't necessarily affect most installations. Most people run multiple interpreters serving a single site, each load-balanced to. Knock out one and it'll be restarted, while the other continues to serve content.
Which brings us to your next point...
mod_ruby -- you do realize pretty much no one in the Ruby world uses Apache, right? It's all mongrels and nginx... But if you must, there's Passenger. [modrails.com]
From +2 insightfull up to +5, down to +1 up to +2 (Score:2)
My Parent is getting modded all the way up and down the scale.
Looks like I struck a cord right there. Hehe.
Flamewar-A-GoGo!
Re: (Score:2)
I believe this is the PHP bug you mention: http://use.perl.org/~Aristotle/journal/33448 [perl.org] .
Re:Goes to show ... (Score:4, Insightful)
So, um, how's jPHP and Jython coming along? Would you deploy a real life application on Jython?
So, um, how's jPHP and Jython coming along? Would you deploy a real life application on Jython?
But I have two questions:
1. What does the relative merit of Jython versus Jruby have to do with the price of tea in China? Are you moving your apps from the buggy MRI to JRuby this week to avoid these security holes?
2. What evidence do you have that Jruby is more appropriate for "real life applications" than Jython? I know people who have deployed real life applications on Jython since before the first checkin of JRuby. For example, Websphere ships with Jython.
http://wiki.python.org/jython/JythonUsers [python.org]
Ruby has some real advantages over Python. But if you don't know them, don't just make stuff up.
Re: (Score:2)
My question about Jython was not rhetorical; I keep hearing people saying it needs more love. And no, I wouldn't give Java the time of day, but it is perhaps quite relevent to those who worry about wobbly concepts like "maturity" in decade-old languages.
Re: (Score:2)
Re: (Score:2)
Outstanding! Now I won't have to port my python code to java to make IT happy. Now that Java is going FOSS - I wonder how their 'don't use open source' policy is going to fly?
Re: (Score:2, Insightful)
The fuck has that to do with anything? "Hey look, people who WORK AT GOOGLE are involved in it, it must be good!"
good news (Score:5, Funny)
Now it's time to start calling up all those RoR sites and use this to convince them to switch the Django.
Someone had to say... (Score:5, Funny)
Technical merit is not a popularity contest. (Score:2)
Basic, COBOL and Visual Basic at some point were all the most popular languages (shudder).
And as always, ruby detractors keep to themselves those catastrophic inherent problems that are glaringly obvious ....
Re: (Score:2)
Proc.kill_troll (Score:2)
Yip, the number one problem in Ruby today is the sheer number of trolls it attracts.
Fortunately I hear Matz is going to make Proc.kill_troll part of the standard library in the next release.
Re: (Score:2)
FUD? (Score:3, Insightful)
Huh? Who lets users enter arbitrary integers to index into arrays? Or let's users submit arbitrary loops for execution? Apart from the statement quoted above, what indication is there that any of these would "crop up" in any but the most contrived circumstances?
--MarkusQ
Re: (Score:2)
The same people that let remote users enter arbitrary data into an SQL query, or who use non-parameterized queries in the first place. Or who set a "logged_in=1" cookie after authentication and check only that value for future verification.
Can you elaborate on this? (Score:2)
The same people that let remote users enter arbitrary data into an SQL query [...]
You mean "if you're stupid enough to let someone sneak arbitrary Ruby code in via a form, then they can use this complex memory corruption attack instead of just opening up a backdoor shell"? Or what?
Re: (Score:2)
Yes, Yes... Everyone is stupid except for you. You never had made a stupid mistake or had a bug or a volnerability... If not then you haven't coded that much, or you are so carful coding that it takes you 30 times as long to get a project done, thus making you a liability to the company as you cannot differieante the difference between perfection and satisifing.
Lets get real, people make mistakes, we code with for the need sometimes security lacks because they will not pay for such carful actions or put va
You don't need an exploit if you're already in... (Score:2)
Everyone is stupid except for you. You never had made a stupid mistake or had a bug or a volnerability.
Oh no, I've been stupid, often enough. I'll happily admit that, because concentrating on the "stupid" but is completely missing the point.
The point isn't that it's stupid to worry about buffer overflows.
The point is that the mechanism you're talking about, code injection attacks similar to the SQL injection attacks, don't need buffer overflows. Because once you've pulled a Ruby code injection attack you've
Re: (Score:2)
When we are talking about users and software we are talking about the users of the libraries. Don't think web users here, think applications. Of course, if you don't do any checking you may have users that submit tricky stuff into your application. Anyway, if you are relying on the platform to do certain checks, it might very well be that applications get vulnerable pretty fast.
Re: (Score:2)
How so? (Score:2)
How so? What array? Where does the user specify the integer? Where in the code is this indexing done (I assmue you're talking about Rails, unless you're just blowing smoke)? On the face of it, your claim here makes no sense.
--MarkusQ
Re: (Score:2)
Yes. Similarly, problems could conceivably occur if you submitted an URL with very many parameters, or a very long one.
But look at the magnitude required. You need an index of over 2^30 to trigger the problem. That's over a billion entries. To make an HTTP request that long, you would need to send over a gigabyte of data to the server. To encode that many parameters in the URL would require even larger volumes. And to cause your "add item" functionality to trigger the bug would require even larger volumes o
I have patched all of my customer's servers (Score:3, Insightful)
I did some testing on an off line server, and then pushed these patches.
I am concerned about "Ruby the Platform". I have dealt with deployment and scaling issues for a few years on a customer project written in Rails + Common Lisp, and as much as I *love* coding in Ruby and Lisp, this experience has also made me appreciate "Java the platform" :-)
Re: (Score:2)
> I have dealt with deployment and scaling issues for a few years
What do you think of modrails [modrails.com]? To me it changes the Rails deployment game entirely... no more mongrel clusters, no more complicated rewrite rules...
Re: (Score:2)
I have not yet looked at modrails, but I just looked at the site that you linked - looks very interesting - thanks!
That said, I am fairly happy with nginx + memcached + mongrel cluster
Re: (Score:2)
No problem! Yup, the thing I like about modrails is that I don't have to allocate my cluster sizes and port ranges and such up front - I can just set RailsMaxPoolSize and then let modrails spin application instances up and down as needed. I used to worry about file uploads - you know, "oh gosh, what if 4 people are uploading files at once, they'll tie up the whole cluster, so let's restrict uploads to just mongrels on ports 8000-8001" - that kind of thing. Nice not to have to worry about that stuff anymo
Re: (Score:2)
I actually like mongrel clusters as an exercise in horizontal scaling. The reason I'd consider modrails is that it's somewhat faster.
Remember, once you've got a mongrel cluster -- complete with "complicated" (read: five simple config lines that you copy and paste) rewrite rules -- it's trivial to put a few more mongrels on another machine.
Re: (Score:2)
> it's trivial to put a few more mongrels on another machine.
True, and right, once you get all the parts (init scripts, monit, ports, etc) working, it's done. But all that goes away with modrails... just keep Apache running and you're all set. Just a lot fewer moving parts. The horizontal scaling is still there, modrails just removes a layer from the architecture - which is nice...
Re: (Score:2)
You still need to setup a reverse proxy to the other servers. The only thing you've done is replaced mongrel with apache.
Re: (Score:2)
> You still need to setup a reverse proxy to the other servers.
> The only thing you've done is replaced mongrel with apache.
Yes, but instead of preallocating a specific port range (and a cluster size) you can set up one port and the number of workers gets expanded as necessary. Plus, you don't need something watching and restarting each worker. Also, you could conceivably remove a layer from your server architecture - rather than:
load balancer web app db
we can have:
load balancer app db
And you'r
Re: (Score:2)
Yes, but instead of preallocating a specific port range (and a cluster size) you can set up one port and the number of workers gets expanded as necessary.
Given two cores, I'm not sure where more than three mongrels would help. Also, there are several projects which do this already, in several ways.
Plus, you don't need something watching and restarting each worker.
Actually, you do -- it's called Apache+modrails. The only difference is that it's marginally more visible when used as mongrel_cluster.
Also, you could conceivably remove a layer from your server architecture
Not the way you're describing -- or at least, not on more than one app server. Or how does Apache distribute tasks to workers on other machines?
My cluster right now is: nginx -> mongrels (with rails) -> db
With modrails, it
Re: (Score:2)
> Given two cores, I'm not sure where
> more than three mongrels would help
Hm, but isn't that assuming that they're CPU bound? I'd think they'd be more likely to be I/O or socket bound, especially if they're dealing with file uploads or calls to S3 or Salesforce or any other long-lasting requests.
> Actually, you do -- it's called Apache+modrails. The only
> difference is that it's marginally more visible when used as mongrel_cluster.
Right, and modrails handles that, so I don't need to see anythin
DoS for ruby? You don't need exploits for that (Score:2, Funny)
I LOVE ruby as a language, but let's be realistic here. All you need for a DOS attack against a ruby-based web application of any complexity is a few dozen users using it as intended. No need to waste time figuring out complicated exploits for that.
Re: (Score:2)
I think you're talking about Rails. Ruby as a web language can be very fast, especially with fcgi or using mongrel as the webserver.
Rails is "slow" because of all the automagic things it does, but it is possible to create a fast and responsive rails application even when it gets heavy users.
Twitter is a perfect example of this.
Re:The real story (Score:4, Insightful)
Re:The real story (Score:5, Funny)
sooo... open source failed? that's what it sounds like you're saying. beware of pitchfork carrying moderators ;)
Re:The real story (Score:5, Insightful)
How did open source fail? Someone who wasn't the original author had access to the code and found the bugs. How quickly it's found is a function of how many qualified people are looking at the code. I didn't RTFA, but presumably Drew Yao, a member of the security team, was security auditing the code. This activity would have been much harder to impossible with closed source code.
I'd say the system worked as advertised here.
Re: (Score:3, Insightful)
This activity would have been much harder to impossible with closed source code.
I'd say the system worked as advertised here.
Re:The real story (Score:4, Insightful)
I didn't say anything about Microsoft. Obviously there are, but the source is much more difficult to obtain. If the source can't be obtained, auditors must use more difficult types of testing, or just hope that the vendor did their job correctly.
My only point was that Apple would have a much more difficult time auditing, say, Office for Mac, than they would with Ruby due to the requirement for source code agreements or using more arcane methods like blackbox testing or disassembly. The same applies to Photoshop, Flash, or any other 3rd party closed-source app.
The victory here is that Ruby was improved by a 3rd party who had ready access to the source. When the source is available, this will happen much more often than when it's not.
Re: (Score:3, Interesting)
Yup, because Microsoft certainly never have exploits such as these discovered...
The difference is who finds them and what happens when they are found. Vulnerabilities in Microsoft products are found either by accident (I pass you some data which should be valid and you choke, or I pass you some data which should be invalid and you don't choke, or you just crash instead of detecting the invalid data and throwing an exception or local equivalent, which is what you SHOULD do EVERY TIME) or by malicious motherfuckers deliberately looking for the above conditions, or disassembling the cod
Re: (Score:2)
I'm sure lots of bugs that have potential security implications get quietly fixed (fixed without a security advisory being sent to the distros) in the opensource world too either because the project has a very tight definition of what they count as a security bug (e.g. insisting on a working code execution exploit before considering a bug a security issue), because the project has no mechnism in place for sending security advisories or simply because the people dealing with the bug don't understand it's sec
Re: (Score:2)
Re:The real story (Score:5, Insightful)
Re: (Score:2)
That's a good point. I don't claim to be sure of anything except that, had the source not been available, those bugs would probably still exist.
In other words, the lifetime of the bugs is substantially decreased. In closed-source apps, less people can audit it, which necessarily means that there's a smaller pool of nice, cooperative people to find the bug.
The people with a financial incentive will still find exploits like they always do -- open or closed.
Re: (Score:2)
Because dishonest hacking cartels would never look at microsoft source code [slashdot.org]!
Funny how open source always wins... (Score:5, Insightful)
Case 1: the code has no bugs: "many eyes make for shallow bugs!" everyone chants.
Case 2: the code has bugs which get reported and fixed. "See, this would have taken much longer if the source was closed!" This claim is impossible to verify objectively but is stated as a fact, regardless of how trivial the bugs are.
Re: (Score:2, Insightful)
And then there are those of us who just don't give a damn about what other people think, but continue to use open source on both our servers and our desktops not because of what other people claim, but because in our experience it works better.
Re: (Score:2, Insightful)
Case 1 is a myth. All software has bugs. Even the best and most thoroughly reviewed code typically at least 1 bug per thousand lines of code. Always. (However, they're not always security related like this.)
Re: (Score:2)
Aaaand then you get people who claim that "Open Source worked!" when a 25 year old bug is squashed.
Re: (Score:2)
Ruby itself is only 13 years old.
I was referring to the 25 year old BSD bug that Slashdot reported on not to long ago. There were people who honestly said that this was Open Source at work.
I get the feeling you are an embittered Microsoftie...am I right?
Not at all. At work I use OS X. For servers, I use FreeBSD. At home, I use Linux.
What I am is sick and tired of zealotry. There are times when open source is great, but every time a major bug is found and fixed, that's not "a victory for open source". And OS X isn't inherently more secure than other major operating systems. But time and again, p
Re: (Score:2)
How did open source fail? Someone who wasn't the original author had access to the code and found the bugs.
Re: (Score:2)
I never claimed he was the first. The point was that these were found *quicker* than if it was solely up to the original authors to find the bugs. "Quicker" is a relative term compared to the alternative. It doesn't mean "first", and it doesn't mean "quick".
Re:The real story (Score:5, Insightful)
A vulnerability in an open source project was found by a third party doing a security audit of the code. The possibility to validate the source code is exactly what open source proponents claim is the reason for open source being more secure. Everybody can have a go, a thousand pairs of eyes see more than one pair, and all that. Try auditing Visual Basic 6 for comparison.
Re:The real story (Score:4, Interesting)
Re: (Score:2)
I'd wager that VB6 is probably fairly safe.
Fundamentally flawed language in many ways, definitely :). But probably fairly safe.
Re: (Score:2)
It is more complex than that. FOSS does not guarantee a given project will be examined - it only provides the opportunity.
Other factors determine the extent of examination: popularity, criticality, etc.
The Linux kernel and Firefox are regularly combed and bugs reported because they are both popular and critical infrastructure.
There are many more projects that don't get combed as often or as thoroughly, and there are legion that don't get examined at all. Ruby falls in here somewhere.
Re: (Score:2)
A testament to either how adopted the Ruby language is or the competency of the maintainers.
I'm rally not a troll; I think they are valid points.
Not just RoR (Score:3, Interesting)
This reminds me of the notorious suidperl vulnerability [ciac.org] from back in the day. In a nutshell, you could use the following code to achieve a root shell from an unprivileged account (apologies if I don't get it exactly right... I don't have an ancient system to verify on):
That was available for how many years? Anyhow, that's much more serious than this Ruby DoS attack. ;)
Re: (Score:2)
I'm not sure that I agree that the perl thing is more serious.
This is an integer overflow bug, which allows someone to write arbitrary code to arbitrary points in memory.
It's just a short matter of time before that is 'weaponized' as TFA puts it, and shellcode inserts are achieved through this.
At this point, this is a remote, instantly-own-your-box without requiring any user access to it at all.
The suidperl issue is a priv escalation, which means you have to have an unpriv'd account in the first place. The
Re: (Score:2)
I'm not sure that I agree that the perl thing is more serious.
Well, I think that's just going to have to go down to the definition of "serious".
The perl hole was:
1. trivial to exploit
2. yielded a root shell
3. wouldn't be super hard to exploit remotely if you think of all the perl CGI that was written back in 1996. Getting write access to a cgi-bin directory was not considered too challenging.
4. perl was ubiquitous back then. Installed on most any *nix machine.
The ruby hole:
1. has not yet been shown to execute arbitrary code
2. is definitely remotely exploitabl
Re: (Score:2)
Yes, even more so with the mindless popularity of Ruby among the programming anti-elite. The thousands of tutorial screencasts teaching non-programmers "how to build a blog in 5 lines" have led to an explosion of horrible sites that every self-respecting coder and/or security analyst dismissed as a big gaping hole.
As it turns out, we were right. How these obvious flaws weren't spotted sooner, that's the true mystery.
Mindless popularity? (Score:2)
Maybe it is popular because it is easy?
If the programming elite are so clever they would have come up with something that allow developers to prototype and put in production things quickly.
You may be right in regards to security, but patronizing people about how they are trying to fulfil a real practical need is frankly beyond the pale.
Re:The real story (Score:5, Insightful)
No. The real story here are the security bugs, precisely as described. This isn't cheerleading - to users of Ruby it really doesn't matter how fast some other imagined patch might have come out from another company for a different product. If I'm running Ruby, I need to know that these bugs exist and that patches can be applied for them.
Drop the us vs them thinking - it doesn't help is pretty much just FUD.
Cheers,
Ian
Re:Confirmation (Score:4, Insightful)
Then what is? Sun Java and Microsoft .NET have both had long histories of security patches. Python is a lot better but nothing is perfect.
At least with a Linux Python/Ruby you get the security fix within hours as part of your regular operating system update. With Java you have to download the whole thing again from Sun's site. With .NET you have to wait for patch tuesday or apply a hotfix manually.
Re:Confirmation (Score:4, Interesting)
Re: (Score:3, Insightful)
Agreed. It also usually doesn't refer to a programming language or environment. At any rate, "enterprise" applications have historically been written in a bunch of languages that don't do array bounds checking. Granted, ruby is supposed to do it, but I mean, seriously - are kids these days so spoiled by JavaScript and VB that this kind of error is a surprise and the biggest bug ever?
Re:Confirmation (Score:4, Insightful)
1. If the interpreter is supposed to do it, except it then turns out it actually doesn't (or doesn't do it correctly), then yes.
2. If the problem occurs in something that is a part of the language itself, or at least part of its standard library/built-in types, or, however you want to define it, if it is in the set of stuff that everyone who has the language installed has installed, and the functionality is used in pretty much any program ever written in the language, then yes.
So, yes.
Re:Confirmation (Score:5, Funny)
No, "Enterprise ready" means they didn't have to deal with that shit on Star Trek.
Re: (Score:2)
Re: (Score:2)
and I for one get really tired of all the Sun Java updates. One particular update path I have to go through with some machines requires downloading 5 or 6 java updates, at 35-50mb EACH, as java trampolines itself up to the latest version.
Re: (Score:2)
what system is this? At least on windows I have never had a problem just downloading the latest java installer from sun and running it regardless of what if any version of sun java was on the machine before.
Re: (Score:2)
It's even easier in Linux... just unpack the archive and move the resulting JDK/JRE directory to where you want it. But that's still a lot more fuss than getting it as part of the system update as you do with the "open" platforms. That's another reason OpenJDK is so welcome.
Re: (Score:2, Insightful)
Actually, considering its age, Java DOESN'T have a "long" history of security patches. Java was designed by security freaks and the security both of the core language and the standard platforms is extensively vetted and tested by security professionals. Which is why you have to look long and hard for news reports of major security breaches in Java.
The Java system is considered to be an integrated whole and new releases have to pass an extensive suite of tests before they are certified. Yes, it's a royal pai
Re: (Score:2)
Re: (Score:2)
Um, what? Can't you just look at the disclosures? Why do I have to spoonfeed you the facts? Are you seriously suggesting even one of the mentioned platforms has had a flawless security record?
Re: (Score:2)
You asserted that Python has a glowing security record compared to Java and .NET. I don't buy it. Prove it. You state things as facts with zero evidence to back it up. In the future, I suggest you not make such assertions unless you can back it up when someone calls you on it. For the record, I will call you on it every time.
Re: (Score:2)
I think you need to look at the disclosure histories yourself.
Assuming all things are equal, .NET has by far the best record. Python in the middle (by raw count), and Java at the end.
Mind you, Python has two 'own your system' unpatched vulnerabilities right now, that are between 6 and 9 months old and still unpatched. They could be less serious than secunia makes them out to be, however, I'm not familiar enough with them to say off the top of my head.
Python 2.3.x [secunia.com]
Python 2.4.x [secunia.com]
Python 2.5.x [secunia.com]
Python 2.6.x [secunia.com]
I'm not
Re: (Score:2)
You're exaggerating the risk of the Java JVM and particularly .NET quite a bit.
If you look at the security hole history of .NET 1.1 [secunia.com], .NET 2.0 [secunia.com], and .NET 3.0 [secunia.com], you'll notice an almost perfect history.
The only true easy own your box was the JPEG parsing vuln that affected a ton of MS products, and that hit .NET as well, due to shared code/modules.
The JVM has been less close to perfect, but its not too bad. You can read about them for JRE 1.4 [secunia.com], JRE 1.5/5 [secunia.com], and JRE 1.6/6 [secunia.com].
I would also say that its not an apples to
ROFL (Score:2)
Re: (Score:2)
Comparing Python to Windows is a bit silly.
A more relevant comparison would be .NET to Python. I think you'll find that .NET fares quite well in that comparison, at least according to the information at Secunia.
Re: (Score:3, Funny)
Oh yes it is. [rubyenterp...dition.com]
Re:message to staff at Apple HQ (Score:5, Insightful)
Re: (Score:2)
Sorry - forgot the *joke* tag...
Yes they have improved the quality of Ruby by doing this.
Re:message to staff at Apple HQ (Score:5, Insightful)
Apple finds serious bugs in Ruby. They tell the Ruby developers. Ruby developers issue patches. That's not sensational.
MS finds a bug in Safari. They tell everyone not to use Safari. I see slight differences. :P
Re: (Score:2)
Look at almost every security advisory issued out there. "Remedy: Do not/restrict usage of X until bug is resolved".
Making this a stab at MSFT just shows you up as an Apple fanboy.
Re: (Score:3, Insightful)
Look at almost every security advisory issued out there. "Remedy: Do not/restrict usage of X until bug is resolved".
Making this a stab at MSFT just shows you up as an Apple fanboy.
Re: (Score:2)
Ignoring that there is a much bigger hole in IE that the Apple bug makes a tiny bit easier to trigger
I would disagree as to which one is the bigger hole.
Anything that lets arbitrary attackers write arbitrary files to protected locations on the local system is worse than IE loading DLLs from known locations.
Why? Simply because if you're able to write files to the computer (outside of cookies and temp) just by having someone visit a website then you've largely owned the computer at that point.
The only thing that restricts the scope of the apple bug is that it only writes to the desktop (which is a stupid a
Re: (Score:2)
Anything that lets arbitrary attackers write arbitrary files to protected locations on the local system is worse than IE loading DLLs from known locations.
Re: (Score:2)
Nice job with the random hyperbole there.
Lets report on this more accurately:
Apple finds serious bugs in Ruby. They tell the Ruby developers. Ruby developers issue patches.
MS finds a bug in Safari. They tell the Apple developers. Apple developers say they wont patch it soon. MS then tells everyone not to use Safari until its fixed.
You're right in that its not the same situation, but when you put all the facts in, rather than trying to cast a one-sided light on the situation, its alot clearer.
PS, the funky quoting style is slashdot's recent bugfest that ignores hard returns thats cropped up lately.
Re: (Score:2)