Yes, they are promising results, but the reason why they can "guarantee" these results is because they already know about them. This is a key distinction from a traditional security audit, where one presumably doesn't know the vulnerabilities before signing the contract.
It's one thing for RealMedia to cause damage (release a product with a security flaw in it). It is another thing to actively exacerbate this damage (release an exploit to the blackhat community for large sums of money, and refuse to tell the vendor what the exploit is).
I understand where you're coming from; the only ones who seem to be directly affected are the poor end-users. However, if people stop using RealPlayer because of the exploits, and IT departments start uninstalling it because all there machines are getting owned, and it affects RealMedia's bottom-line, you can be sure as hell that's damage.
To elaborate, Evgeny is threatening damage to Real (by this exploit) unless they pay up a sizable sum of money to purchase the exploit (whether or not he'd sell it to Real is another matter, although Real could always pose as a client and then purchase it).
I know Real has got a pretty scummy reputation, but that's no excuse to condone this behavior.
Hear hear! For instance, the first thing I thought when I saw this exploit was, "Crap, what about my webhost!" (I don't really care much about my home Linux install, where the exploit does work, because it's strictly local). Happily enough, the exploit ended with "vmsplice: Function not implemented" and all was good.
Of course, whether or not using a shared host is a good security practice is another issue altogether.;-)
Re:Bet there still isn't a decent "Stop!" button
on
HTML V5 and XHTML V2
·
· Score: 2, Insightful
This is a novel technique (the unique, hard to guess string, which easily could be a hash of the document and a secret salt the website has) I have not seen before, but this merely punts the issue to the browsers. It cannot be solved there (as you mention); in fact, it does not even begin to solve it: think about the legacy browsers floating around the web. I don't even trust browser vendors to lock down all of this code: they also have their own security bugs.
There is also the minor point that your method is almost completely incompatible with DOM, but I'll overlook that for now.:-)
I've already moderated in this discussion, but I'll bite. Am I?
You people need to stop skirting around the issue by inventing new markup languages and actually solve the problems with proper libraries for each language. There is already a solution for PHP (HTML Purifier): how about more languages?
Any HTML filtering library will be complicated, but it will be much less complicated than a web-browser, which actually has to do things with the HTML. All a filter has to do is validate.
I recently read an article on the New Yorker discussing how the United States strong-arms other countries into adopting our own stringent Intellectual Property laws. It just goes to show the continued stance of our government in this area of policy, a stance that is not going to change any time soon.::sigh::
Great, then we'll have sound clips of "FUCK YOU!" sprouting up all over Wikipedia.;-)
On a more serious note, there are many problems with this idea. First and foremost, open sound recordings are few-and-far-between ("let's take pictures" but not "let's bring an audio-recorder to hear an elephant roar!") Then, there's the trouble of Wikimedia insisting on using a free media formats (namely Ogg) which have poor native support (you can't expect teachers to know how to download codecs, heh?) and a buggy/slow/experimental in-browser media player. Not to mention bandwidth concerns (no, not for Wikimedia, rather, for the school! Slow internet connections = slow downloads = restless kids). It worked well for Encarta, where the sound-clips were directly in your CD drive, but is more difficult to realize effectively on the Internet.
That being said, Wikipedia does have an expanding collection of pronunciation and spoken article recordings.
Yes, but any sysadmin worth their salt doesn't blindly install new versions of mission critical software until they make sure that it does indeed work properly.
What you're missing is that fact that PHP uses the three digit version numbering system to mean something slightly different than what you're used to. Increments in the 0.x.0 number indicate, besides major changes in the language, that extension compatibility was broken and thus they need to be recompiled (to see a great example of this, check PHP 4.4). 0.0.x releases do contain feature releases, but you don't have to worry about extensions breaking.
Firefox does the same thing too, except they end up stepping on extension authors feet when they increment the third version number! That's why they introduced a fourth number 0.0.0.x for memory leak / security fixes. But Firefox has the luxury of an auto-update system: something PHP doesn't have. It is in both sysadmin's and PHP's developer's best interests to not be releasing new versions every other week.
Kerning adjustments seem pretty low on the list of reasons IMHO.
You are partially correct. Kerning alone won't make print more attractive than web documents. However, kerning is only one part out of many things one can do to text (justification, hyphenation, smaller line-lengths, line-spacing, judicious use of emphasis, indentation, ligatures, etc.) to make it more readable, i.e. typography. The sum of all these adjustments, while not consciously visible to the reader, most definitely has an effect on the overall desirability of print media.
Aesthetically speaking, it's not very pretty, and even one 5 MB image can be pretty devastating to a cable connection. And I doubt the ability of whatever image-host it was to cache the image properly: you need the right headers to be sent and so many people get these things wrong.
There are also cases where people crash entire operating systems by using up all the video card's memory, see ha.ckers.org/imagecrash.html (WARNING: may crash you, though latest version of IE is not affected).
You could also use the technique to take down an image-hosting provider: use the large image as your signature in a popular webforum and use up all their bandwidth.
Thanks for the perspective into the professional world of music! I am a student musician, so my account is what I see, and probably not representative of the larger world out there, even if it does jive well with our perspectives on development.
I think that security is harder because virtually no one gets it right the first time...or the second...or the third...
Well, it depends on your definition of "the first time." The first time of what? Writing any applications at all? Writing applications for that specific domain?
Well, if you wanted to get really technical about it, the conductor's work is mostly done before the performance, so that any reasonably proficient orchestra would be able to do a reasonably good run sans the conductor.
Conducting, however, is a lot harder than it looks, especially during rehearsal. It requires the simultaneous processing of the score (possibly twenty plus lines going on simultaneously), time (not so easy once you get into funky metric changes), expression (precisely what the conductor is all about) while keeping track of mistakes that happened during the piece even though not stopping immediately. It's extremely easy to see when a conductor is inexperienced, boring, or hasn't looked over their music properly.
For conductors of student groups, they also have to keep the members of the ensemble engaged through tasteful storytelling while not completely going off tangent, they must be extremely creative in figuring out how to get their point across, they must be careful not to over-rehearse a section, etc etc etc.
Ask any marching band student turned drum major. Being a good musician does not mean you'll be a good conductor, and a more generalized notion is the core meaning of most of the other analogies offered by Slashdotters around here.
At least they don't assign you karma during elections. "I'm sorry, but your vote is not going to be counted because you have had a history for voting for the wrong presidents in the past."
JavaScript is a programming language. It is turing complete. The halting problem for it, then, is undecidable, making it impossible for any browser to detect all infinite loops / large amounts of memory/cpu consumption.
If theory makes you gag, check out this thread on JavaScript Denial of Service for a list of concrete examples. All of the samples are extremely effective at taking out all browsers (IE, Firefox and Opera alike).
Anyway, the reason why DoS's aren't actively pursued by the black-hat community is that it's very difficult to put them to good use. Sure, it will annoy someone, but it's hard to monetize, etc.
I wholeheartedly agree. While extensions encourage modularization, they're also a convenient way to duck out of having to implement extremely important functionality. Who do you trust more: some random developer hacking together a ball of JavaScript and XUL, or an official extension that has been approved by Mozilla's rigorous review method?
More likely than not your woes are caused by a misbehaving extension. For example, when I upgraded to Firefox 2.0, there was unbelievable performance degradation: it would take a second to switch from to tab to tab. I checked again from a clean profile and the problem was gone: the offending extension was CookieSafe, which I uninstalled promptly (and replaced with another extension).
Slashdot Mirror
Yes, they are promising results, but the reason why they can "guarantee" these results is because they already know about them. This is a key distinction from a traditional security audit, where one presumably doesn't know the vulnerabilities before signing the contract.
It's one thing for RealMedia to cause damage (release a product with a security flaw in it). It is another thing to actively exacerbate this damage (release an exploit to the blackhat community for large sums of money, and refuse to tell the vendor what the exploit is).
...this is an exploit, after all.
I understand where you're coming from; the only ones who seem to be directly affected are the poor end-users. However, if people stop using RealPlayer because of the exploits, and IT departments start uninstalling it because all there machines are getting owned, and it affects RealMedia's bottom-line, you can be sure as hell that's damage.
Mod parent up!
To elaborate, Evgeny is threatening damage to Real (by this exploit) unless they pay up a sizable sum of money to purchase the exploit (whether or not he'd sell it to Real is another matter, although Real could always pose as a client and then purchase it).
I know Real has got a pretty scummy reputation, but that's no excuse to condone this behavior.
Hear hear! For instance, the first thing I thought when I saw this exploit was, "Crap, what about my webhost!" (I don't really care much about my home Linux install, where the exploit does work, because it's strictly local). Happily enough, the exploit ended with "vmsplice: Function not implemented" and all was good.
;-)
Of course, whether or not using a shared host is a good security practice is another issue altogether.
This is a novel technique (the unique, hard to guess string, which easily could be a hash of the document and a secret salt the website has) I have not seen before, but this merely punts the issue to the browsers. It cannot be solved there (as you mention); in fact, it does not even begin to solve it: think about the legacy browsers floating around the web. I don't even trust browser vendors to lock down all of this code: they also have their own security bugs.
:-)
There is also the minor point that your method is almost completely incompatible with DOM, but I'll overlook that for now.
I've already moderated in this discussion, but I'll bite. Am I?
You people need to stop skirting around the issue by inventing new markup languages and actually solve the problems with proper libraries for each language. There is already a solution for PHP (HTML Purifier): how about more languages?
Any HTML filtering library will be complicated, but it will be much less complicated than a web-browser, which actually has to do things with the HTML. All a filter has to do is validate.
Basically, yes. Although I don't see why you'd tell off someone from your email address, I'd spoof my mortal enemy Bob's email.
I recently read an article on the New Yorker discussing how the United States strong-arms other countries into adopting our own stringent Intellectual Property laws. It just goes to show the continued stance of our government in this area of policy, a stance that is not going to change any time soon. ::sigh::
Great, then we'll have sound clips of "FUCK YOU!" sprouting up all over Wikipedia. ;-)
On a more serious note, there are many problems with this idea. First and foremost, open sound recordings are few-and-far-between ("let's take pictures" but not "let's bring an audio-recorder to hear an elephant roar!") Then, there's the trouble of Wikimedia insisting on using a free media formats (namely Ogg) which have poor native support (you can't expect teachers to know how to download codecs, heh?) and a buggy/slow/experimental in-browser media player. Not to mention bandwidth concerns (no, not for Wikimedia, rather, for the school! Slow internet connections = slow downloads = restless kids). It worked well for Encarta, where the sound-clips were directly in your CD drive, but is more difficult to realize effectively on the Internet.
That being said, Wikipedia does have an expanding collection of pronunciation and spoken article recordings.
Yes, but any sysadmin worth their salt doesn't blindly install new versions of mission critical software until they make sure that it does indeed work properly.
What you're missing is that fact that PHP uses the three digit version numbering system to mean something slightly different than what you're used to. Increments in the 0.x.0 number indicate, besides major changes in the language, that extension compatibility was broken and thus they need to be recompiled (to see a great example of this, check PHP 4.4). 0.0.x releases do contain feature releases, but you don't have to worry about extensions breaking.
Firefox does the same thing too, except they end up stepping on extension authors feet when they increment the third version number! That's why they introduced a fourth number 0.0.0.x for memory leak / security fixes. But Firefox has the luxury of an auto-update system: something PHP doesn't have. It is in both sysadmin's and PHP's developer's best interests to not be releasing new versions every other week.
You are partially correct. Kerning alone won't make print more attractive than web documents. However, kerning is only one part out of many things one can do to text (justification, hyphenation, smaller line-lengths, line-spacing, judicious use of emphasis, indentation, ligatures, etc.) to make it more readable, i.e. typography. The sum of all these adjustments, while not consciously visible to the reader, most definitely has an effect on the overall desirability of print media.
Aesthetically speaking, it's not very pretty, and even one 5 MB image can be pretty devastating to a cable connection. And I doubt the ability of whatever image-host it was to cache the image properly: you need the right headers to be sent and so many people get these things wrong.
There are also cases where people crash entire operating systems by using up all the video card's memory, see ha.ckers.org/imagecrash.html (WARNING: may crash you, though latest version of IE is not affected).
You could also use the technique to take down an image-hosting provider: use the large image as your signature in a popular webforum and use up all their bandwidth.
No, no, no, not one megapixel, 0.000001 MP! (If your magic is that low, you probably need to restock on pots.)
Thanks for the perspective into the professional world of music! I am a student musician, so my account is what I see, and probably not representative of the larger world out there, even if it does jive well with our perspectives on development.
I think that security is harder because virtually no one gets it right the first time...or the second...or the third...
Well, it depends on your definition of "the first time." The first time of what? Writing any applications at all? Writing applications for that specific domain?
Well, if you wanted to get really technical about it, the conductor's work is mostly done before the performance, so that any reasonably proficient orchestra would be able to do a reasonably good run sans the conductor.
Conducting, however, is a lot harder than it looks, especially during rehearsal. It requires the simultaneous processing of the score (possibly twenty plus lines going on simultaneously), time (not so easy once you get into funky metric changes), expression (precisely what the conductor is all about) while keeping track of mistakes that happened during the piece even though not stopping immediately. It's extremely easy to see when a conductor is inexperienced, boring, or hasn't looked over their music properly.
For conductors of student groups, they also have to keep the members of the ensemble engaged through tasteful storytelling while not completely going off tangent, they must be extremely creative in figuring out how to get their point across, they must be careful not to over-rehearse a section, etc etc etc.
Ask any marching band student turned drum major. Being a good musician does not mean you'll be a good conductor, and a more generalized notion is the core meaning of most of the other analogies offered by Slashdotters around here.
Whoever modded this flamebait doesn't have their sarcasm-detector tuned properly today.
Gah, nevermind. You know the saying: if you think someone said something unbelievably stupid, you're probably misunderstanding.
Yes. Ever heard of "work-for-hire"?
But then none of the other machines would get any ports!
At least they don't assign you karma during elections. "I'm sorry, but your vote is not going to be counted because you have had a history for voting for the wrong presidents in the past."
JavaScript is a programming language. It is turing complete. The halting problem for it, then, is undecidable, making it impossible for any browser to detect all infinite loops / large amounts of memory/cpu consumption.
If theory makes you gag, check out this thread on JavaScript Denial of Service for a list of concrete examples. All of the samples are extremely effective at taking out all browsers (IE, Firefox and Opera alike).
I am more concerned about pages that can crash browsers without the intervention of JavaScript. This includes imagecrash (may crash you!), mailto crash, and an huge XML file crash. They should be preventable.
Anyway, the reason why DoS's aren't actively pursued by the black-hat community is that it's very difficult to put them to good use. Sure, it will annoy someone, but it's hard to monetize, etc.
I wholeheartedly agree. While extensions encourage modularization, they're also a convenient way to duck out of having to implement extremely important functionality. Who do you trust more: some random developer hacking together a ball of JavaScript and XUL, or an official extension that has been approved by Mozilla's rigorous review method?
More likely than not your woes are caused by a misbehaving extension. For example, when I upgraded to Firefox 2.0, there was unbelievable performance degradation: it would take a second to switch from to tab to tab. I checked again from a clean profile and the problem was gone: the offending extension was CookieSafe, which I uninstalled promptly (and replaced with another extension).