You may be interested to know that AFS has implemented a variant of this feature. The conceit is that filenames can contain a magic string @sys, which gets substituted with the "sysname" of a particular system. This means if someone publishing software over AFS wants to have multi-platform support, they merely have to setup a directory divided by sysname and have compiled versions of the software for each system type they wish to support.
The first trap you will fall into thinking about this is that it should be the end-all security policy, and will solve our problems. It won't. That's not the intent, and also impossible given our diverse browser ecosystem.
The ability to tell the browser, via out-of-band, non XSS-able information, that certain scripts should not be executed, however, is a very powerful defense in depth measure, and makes it one step harder for attackers to make an attack work.
Why would Microsoft ever want to hire a cadre of Linux kernel developers? It's more likely that Microsoft would find some-odd patent in its catalog and sue them.:-)
As a typical geek, I don't care much about AIX's concurrent updates. If I were a corporate dude, I probably wouldn't care too much about AIX's concurrent updates (I'd have to have a lot of other good reasons for switching to AIX).
As a geek who runs Jaunty, I care a lot about Ksplice. It's awesome. I can run it on all of my boxen. If I were a geek who runs another distro, I don't care much about Ksplice, except maybe for the fact that we're starting to get rebootless updates into mainstream. But if I were a corporate dude, I care a lot about Ksplice: if I pay these dudes, I can get these updates for *any* system. I don't need no special kernel. I don't need no complex process. I just fork over money and these guys make the magic happen. That's powerful.
Ksplice is still pretty neat, and worth playing around with (it's very very quick: after installing it's a little like boom boom boom, patches are applied). It also means that you can keep a fully patched kernel without having to compile one yourself every time a new patch comes out; a little different from being rebootless, but eminently useful for us mere mortals.
That's a collection of shell scripts around the free software Ksplice tool that
merely automates the task of downloading the Fedora kernel. (The Ksplice software
has been released for over a year, and is also packaged in Ubuntu and in Debian, although the ksplice.com
apt repo has newer versions.)
Ksplice's Uptrack service is a way to automatically apply Ksplice updates that have
been vetted for safety by the Ksplice developers, which is a much more convenient
thing unless you like reading every kernel patch daily and testing the resulting
Ksplice patch yourself.
Note: Not all security updates support HotPatching, and some security updates that support HotPatching might require that you restart the server after you install the security updates.
That is an interesting question, no? After all, this company has made all of its software open-source, and if someone else is able generate update, they can "cut in" on Ksplice's market share. (This is forking the service, you're speaking of, not really the software.)
But this is not really a problem unique to Ksplice; it applies to any service based open-source model. And as such, what Ksplice has going for it is expertise: they were the ones who developed the Ksplice tools, they have an intimate understanding of the interplay between the kernel and hot updates, they are the ones who know how to "tweak" patches in order to make them work with the Ksplice system (as I understand, there are some nontrivial transforms necessary for certain updates).
So, they're doing the common "commercial open source" thing where the software (the application, the kernel patcher) is open source, but it's also tied to a service (the actual kernel patches) which is not so (free for Jaunty, but if you want a different kernel you'll have to pay Ksplice for support). So the Terms of Service applies to the service, which is really quite sensible.
If you read the CVE advisory carefully, the vulnerability is a faulty access policy for allowing extension installation by web-based JavaScript.
Yes, the technique is old, in that it's been around since iframes and CSS have been around, but we haven't really seen it in malware websites; most attackers use less sophisticated but still effective methods.
Anyone who's been in webappsec for a while will tell you that referers are notoriously unreliable. Anyway, I did a quick test and the referer is that of the previous iframe page. So if I'm browsing Google inside an iframe, Google has no way of knowing it's in an iframe except that the initial page was referred from our website (a perfectly legitimate case that could have been triggered by a link to their website).
Well, the point about the attack is the user doesn't know their being phished. They think they're just pressing play on a video box, or following a link, or some other innocuous action on a perfectly reasonable, anonymous website on the web.
It's a bit like CSRF, except the browser has no way of telling whether or not the click through the iframe was legitimate or not, whereas with CSRF you could at least detect whether or not the form submission came from the same website. A clickjack is functionally equivalent to the user going to that website and making the action of their own accord.
It is most certainly fixable, but it is not, which is why it's a zero-day.
In its most primitive form, it basically involves taking an iframe, figuring out where the link part/form part is, and then tricking the user into clicking it.
This seems very clunky and hacky, but I suspect that the speakers at the OWASP talk have gotten this technique to work well enough so that it is both transparent and highly effective. Can you think of a website that needs you to click, say, a play button in order to view content? That click may be hijacked through an invisible iframe to execute an action on another website.
You are correct that there are only 5 nitrogenous bases that make up DNA and RNA, but there are 8 nucleic acids; the 4 DNA monomers have the sugar deoxyribose, while the 4 RNA monomers have the sugar ribose.
You know what? I'm sick and tired of the fact that every PHP related post to Slashdot ends up sludgefest of old jokes, one-line jabs at PHP, and misinformation.
Official ending of PHP4 support is a big thing in the PHP community. If you're a reader of Planet-PHP, you'll know this; for almost all of 08/08/08 there was nothing but end-of-life celebrations from the bloggers. The community has done an exceptional job at getting developers, open-source projects and hosters alike to migrate to PHP5 for such a heavily used language. And we will have to surmount even bigger difficulties for PHP6 and Unicode, which unlike PHP5, breaks backwards compatibility with any project that treats strings as binary data. Migrating PHP4 to PHP5 is not difficult; often it's as simple as an edit to the server migration. PHP6 will definitely demand code changes.
For those of us who use and "have to deal with" (yes, we have our annoyances too) with PHP on a daily basis, this is good news. For the rest of you, please contribute something meaningful, or forever hold your peace.
I have mod points, but I have to point out here that Opera Sync currently only works with your bookmarks and your speed dial, making it Opera's built-in equivalent of Foxmarks (which I myself have been using happily). It is no Google Browser Sync replacement.
I should add, whether or not we condone this behavior has no bearing on the issue at all. This is a clear issue of a product arising to supply a need; if we want to curb this capitalistic instinct we'll have to get the Russian Government to do something for the "greater good."
What is the greater good? For me it's pretty clear: software without security vulnerabilities. Is it reasonable to expect security researchers not to make money off their knowledge? Is it reasonable to expect software not to have security problems? It is reasonable to expect people with vulnerabilities to make them public and not sell them to the black market?
Probably not. Still, we can dream (or say OPEN-SOURCE, although that really doesn't fix the problem if it never goes public.)
Slashdot Mirror
Dude, just jump ship already. I just read Slashdot these days for the perverse pleasure of silly stories. :-)
P.S. This article hit front page YC and Proggit several hours before Slashdot.
You may be interested to know that AFS has implemented a variant of this feature. The conceit is that filenames can contain a magic string @sys, which gets substituted with the "sysname" of a particular system. This means if someone publishing software over AFS wants to have multi-platform support, they merely have to setup a directory divided by sysname and have compiled versions of the software for each system type they wish to support.
The first trap you will fall into thinking about this is that it should be the end-all security policy, and will solve our problems. It won't. That's not the intent, and also impossible given our diverse browser ecosystem.
The ability to tell the browser, via out-of-band, non XSS-able information, that certain scripts should not be executed, however, is a very powerful defense in depth measure, and makes it one step harder for attackers to make an attack work.
Security is a war of attrition. Bring it on.
That's because there is none; we agree. :-P
Don't use it, company I work for doesn't use it, don't care.
Why would Microsoft ever want to hire a cadre of Linux kernel developers? It's more likely that Microsoft would find some-odd patent in its catalog and sue them. :-)
As a typical geek, I don't care much about AIX's concurrent updates. If I were a corporate dude, I probably wouldn't care too much about AIX's concurrent updates (I'd have to have a lot of other good reasons for switching to AIX). As a geek who runs Jaunty, I care a lot about Ksplice. It's awesome. I can run it on all of my boxen. If I were a geek who runs another distro, I don't care much about Ksplice, except maybe for the fact that we're starting to get rebootless updates into mainstream. But if I were a corporate dude, I care a lot about Ksplice: if I pay these dudes, I can get these updates for *any* system. I don't need no special kernel. I don't need no complex process. I just fork over money and these guys make the magic happen. That's powerful.
Pointless or improvement?
Ksplice is still pretty neat, and worth playing around with (it's very very quick: after installing it's a little like boom boom boom, patches are applied). It also means that you can keep a fully patched kernel without having to compile one yourself every time a new patch comes out; a little different from being rebootless, but eminently useful for us mere mortals.
That's a collection of shell scripts around the free software Ksplice tool that merely automates the task of downloading the Fedora kernel. (The Ksplice software has been released for over a year, and is also packaged in Ubuntu and in Debian, although the ksplice.com apt repo has newer versions.) Ksplice's Uptrack service is a way to automatically apply Ksplice updates that have been vetted for safety by the Ksplice developers, which is a much more convenient thing unless you like reading every kernel patch daily and testing the resulting Ksplice patch yourself.
Yeah. Rebootless updates. Uh-huh.
I'm sure if you talk to them, they can set you up with a pricing model for update streams for these distributions. :-)
That is an interesting question, no? After all, this company has made all of its software open-source, and if someone else is able generate update, they can "cut in" on Ksplice's market share. (This is forking the service, you're speaking of, not really the software.)
But this is not really a problem unique to Ksplice; it applies to any service based open-source model. And as such, what Ksplice has going for it is expertise: they were the ones who developed the Ksplice tools, they have an intimate understanding of the interplay between the kernel and hot updates, they are the ones who know how to "tweak" patches in order to make them work with the Ksplice system (as I understand, there are some nontrivial transforms necessary for certain updates).
So, they're doing the common "commercial open source" thing where the software (the application, the kernel patcher) is open source, but it's also tied to a service (the actual kernel patches) which is not so (free for Jaunty, but if you want a different kernel you'll have to pay Ksplice for support). So the Terms of Service applies to the service, which is really quite sensible.
If you read the CVE advisory carefully, the vulnerability is a faulty access policy for allowing extension installation by web-based JavaScript.
Yes, the technique is old, in that it's been around since iframes and CSS have been around, but we haven't really seen it in malware websites; most attackers use less sophisticated but still effective methods.
Anyone who's been in webappsec for a while will tell you that referers are notoriously unreliable. Anyway, I did a quick test and the referer is that of the previous iframe page. So if I'm browsing Google inside an iframe, Google has no way of knowing it's in an iframe except that the initial page was referred from our website (a perfectly legitimate case that could have been triggered by a link to their website).
Well, the point about the attack is the user doesn't know their being phished. They think they're just pressing play on a video box, or following a link, or some other innocuous action on a perfectly reasonable, anonymous website on the web.
It's a bit like CSRF, except the browser has no way of telling whether or not the click through the iframe was legitimate or not, whereas with CSRF you could at least detect whether or not the form submission came from the same website. A clickjack is functionally equivalent to the user going to that website and making the action of their own accord.
It is most certainly fixable, but it is not, which is why it's a zero-day.
In its most primitive form, it basically involves taking an iframe, figuring out where the link part/form part is, and then tricking the user into clicking it.
This seems very clunky and hacky, but I suspect that the speakers at the OWASP talk have gotten this technique to work well enough so that it is both transparent and highly effective. Can you think of a website that needs you to click, say, a play button in order to view content? That click may be hijacked through an invisible iframe to execute an action on another website.
The good folks at Google recently raised this topic on the WHATWG mailing list, you can read more about it here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/016284.html
You sir, have not RTFA.
You are correct that there are only 5 nitrogenous bases that make up DNA and RNA, but there are 8 nucleic acids; the 4 DNA monomers have the sugar deoxyribose, while the 4 RNA monomers have the sugar ribose.
You know what? I'm sick and tired of the fact that every PHP related post to Slashdot ends up sludgefest of old jokes, one-line jabs at PHP, and misinformation.
Official ending of PHP4 support is a big thing in the PHP community. If you're a reader of Planet-PHP, you'll know this; for almost all of 08/08/08 there was nothing but end-of-life celebrations from the bloggers. The community has done an exceptional job at getting developers, open-source projects and hosters alike to migrate to PHP5 for such a heavily used language. And we will have to surmount even bigger difficulties for PHP6 and Unicode, which unlike PHP5, breaks backwards compatibility with any project that treats strings as binary data. Migrating PHP4 to PHP5 is not difficult; often it's as simple as an edit to the server migration. PHP6 will definitely demand code changes.
For those of us who use and "have to deal with" (yes, we have our annoyances too) with PHP on a daily basis, this is good news. For the rest of you, please contribute something meaningful, or forever hold your peace.
A quick note for unfortunate souls who actually try googling "Knuth-Pass line breaking", it's Plass, not Pass.
I have mod points, but I have to point out here that Opera Sync currently only works with your bookmarks and your speed dial, making it Opera's built-in equivalent of Foxmarks (which I myself have been using happily). It is no Google Browser Sync replacement.
Of course, there's still the difficulty that the browser itself is compromised, or that the network connection is being sniffed.
I think the kyps.net solution is best, albeit cumbersome, and if you want true security, you'll need to implement the service yourself.
IIRC one very simple approach to privacy was to notify people when someone checked on their position, and who it was.
From my understanding of RFID, this is not technically feasible...
I should add, whether or not we condone this behavior has no bearing on the issue at all. This is a clear issue of a product arising to supply a need; if we want to curb this capitalistic instinct we'll have to get the Russian Government to do something for the "greater good."
What is the greater good? For me it's pretty clear: software without security vulnerabilities. Is it reasonable to expect security researchers not to make money off their knowledge? Is it reasonable to expect software not to have security problems? It is reasonable to expect people with vulnerabilities to make them public and not sell them to the black market?
Probably not. Still, we can dream (or say OPEN-SOURCE, although that really doesn't fix the problem if it never goes public.)