I'm waiting for somebody to suggest that you could take a single PC, provide it with four graphics cards, plug a USB hub and four sets of keyboard and mice into it, and use it to serve four users.
And *all* local root exploits are already patched in Linux, right?
I'll admit I don't keep as up-to-date on such matters as I should, but to get access to my data on the machine in question a user would have to hack root and break out of a chroot environment while working in a highly restricted environment with no daemon processes running as root, root logins disabled except for console, and a very restricted set of suid-root binaries installed. Also the kernel in question has a patch applied intended to provide additional isolation between processes associated with different servers, which may make this even more tricky.
I suspect hacking root on this system is very difficult.
If you're THAT concerned about this issue, I assume you're going to call up your ISP and transition your site onto dedicated machines?
My site is low volume. A dedicated machine with similar performance and uptime guarantees would cost somewhere in the region of £200 extra per month, which is a very sizeable chunk of its profits. If I had to carry this cost, I would abandon the business as not worth running.
In any case, I'm not sure I get your distinction between objects as code vs. user interface level features. OLE is code. An ActiveX object is implemented as code but it generally has a UI. Is a Java Bean a user interface level feature? How about an EJB? Are you saying that "the idea of a button is a user interface level object, but a JButton is a code level object?".
Effectively, yes. What I see here is a patent on a specific type of interaction which doesn't really refer to implementation details, except in passing. The core of the patent is about how the user can interact with the e-mail addresses, not how the program is organised to achieve this effect.
Which is even worse than an implementation detail patent, IMO. The software industry tried to protect 'look and feel' through copyright in the 80s, and failed. Now they're trying to do it through patents, instead. And they might succeed.
People will get in through a simple sploit as always and then use a local root sploit as always. getting there is easier than this attack and once you are there you can just read the rsa key file, or read it from another processes instead of trying to guess what it is from cache behaviours.
That depends on such an exploit being available. There isn't always a known way of achieving this in any given system. For instance, do you know any way on a stock Linux system (let's say kernel 2.4.29) of breaking out of a chroot environment? I don't know that it can't be done, but my suspicion is that it's probably quite hard.
This exploit, also, is quite hard. But even exploits like this can be automated, and I don't find it too improbable that kits aimed at grabbing keys from specific pieces of software might start becoming available, do you? And once such kits are available, then the difficulty of the exploit is not going to put anyone off.
You would think that in a legal document like this if they meant OLE they would have said OLE.
Patents are often left intentionally ambiguous, so that they can later claim that something slightly outside what they were originally intending is covered by it. They said something that might be construed to mean OLE, or indeed any other mechanism that provides a similar function. It certainly is clear that they were talking about objects as a user interface level feature, not a code level one.
It depends what you mean by 'object'. In this case, the patent is talking in terms of user interface objects, possibly intending reference to other MS technologies like OLE that use the term in a very specific fashion. This is a lot more advanced and specific than the kind of object that you need to use to program in a pure-OO programming language.
The best solution is to just fix the crypto libraries as a short term solution, and for Intel to fix the chip in future iterations as a long term solution.
Fixing the crypto libraries is actually a non-trivial task. There are many of them and ensuring there is no information leakage is very difficult to achieve.
Fixing the chip may well be impossible -- it sounds to me like the only way to prevent this kind of thing from being a problem is to give each thread its own instruction fetch pipeline, dedicated execution units and dedicated cache lines. Which is, in effect, dropping HT altogether and switching to dual cores instead.
Yes, and they keep saying "how much did you give to my campaign?"
Then kick them out and replace them with a new bunch that do care about the ordinary people. One the main points of democracy is to help prevent corruption, but it doesn't work if the people sit back and let it happen.
That's good advice, but many people cannot afford to follow it. Specialist crypto hardware is too expensive for most users, and keeping a PC in a physically secure environment can be difficult and contradictory with other important considerations. There are many thousands of small internet-based businesses who simply cannot afford this level of protection, and must rely on "secure" servers rented from virtual server farms. Fixing problems like this quickly after they are discovered is important to help protect these people.
If you've spent a lot of time working on something, it's obviously important to you. That doesn't mean that it's important to everyone else.
Well, no, however it is important to many people.
I, like many others here, run an e-commerce web site on Linux servers. In my case, my servers are virtual servers shared with other users who I do not have any knowledge of at all.
If the server used HT, it would be possible for one of those other users to run an exploit on the server to crack my e-commerce site's private key. Fortunately it doesn't, but my ISP could upgrade at any time...
Hence, this is an issue that effects me and my customers, and I seriously hope that a fix finds itself into either apache mod_ssl or the mainline Linux kernel PDQ.
This fix would have to modify how the OS handles the cache
Actually, I believe the best fix is to change the scheduler so that it doesn't schedule processes from different users on the same physical CPU at the same time.
It isn't something Intel can fix, except by removing hyperthreading. The fact of the matter is that if you have two processes running simultaneously on the same processor, one of them can determine things about what the other is doing based on how many execution units of what type it seems to have access to, how long data remains in the cache, things like that. It's a fundamental problem that can only be fixed by the OS kernel denying use of hyperthreading to processes that need to be kept separate from one another.
I don't think so. I haven't used this project, but I don't suspect it includes some of the features that are included in this patent's claims, specifically displaying a graphical icon adjacent to e-mail addresses.
It might be that this is an obvious extension of something BBDB does, but that's for a court to decide, unfortunately.
That post was about a different patent, which I haven't read, that concerned automatic completion.
Also, this patent isn't about treating e-mail addresses as 'objects'. That's just a gross oversimplification of what it deals with that has been snagged from the summary. The claims talk about displaying e-mail addresses in a message preview pane with icons attached to them to provide more information and enable the user to manipulate them.
If you look at the article, the patent is on treating an email address as an object.
And if you look at the patent, it's about a user interface that displays icons next to e-mail addresses to give extra information about them (having looked them up in your address book to find that information).
None of these are actually prior art for this patent, which is about a specific user interface for manipulating e-mail addresses. If you can find an application dating from at the latest mid-90s that showed e-mail addresses with an icon that varied according to the results of a database lookup to determine what kind of address it was, that is prior art.
The problem is that while this is an obvious idea, I think MS were actually the first to do it.
While this is funny, it shows that you only read the summary and not the actual patent, which is for displaying e-mail addresses in a particular fashion in the user interface of an e-mail client, that is showing them with adjacent icons that vary according to the type of address and can be manipulated (e.g. via drag and drop), as Outlook does.
Because the USPTO has a right to issue patents, this kind of action could not succeed. My understanding is that the laws that enable them to issue patents do not require them to ascertain that the patent isn't for something ridiculously trivial like this one, therefore they have performed their duty as described in relevant laws and there is nothing anyone can do about it.
Except bring political pressure against it. Have you talked to your political representatives at every possible level of government and asked them to do something about this problem?
(1) there ought to be a big warning box with an enforced reading period (like when you install an xpi package) explaining the potential security problems, and (2) chances are, only power users are going to be playing with this anyway.
Simply set up a script that grabs the title and author of the book, looks it up at a selection of free e-book sites (e.g. project gutenberg, baen.com, etc.) and adds a link if it finds it. Et voila!
Many do at present. On firefox, see "Tools/Options/General/Fonts and Colors". You can also use plugins that have existed for ages that override site supplied style sheets.
Slashdot Mirror
No, it's not just you.
I'm waiting for somebody to suggest that you could take a single PC, provide it with four graphics cards, plug a USB hub and four sets of keyboard and mice into it, and use it to serve four users.
It's "revenge of the mini"...!
He's trying to install a version of Windows that's nearly 4 years old. He can't expect the latest drivers to be included in it.
He should get a more recent... oh, wait, that is the most recent version, isn't it?
And *all* local root exploits are already patched in Linux, right?
I'll admit I don't keep as up-to-date on such matters as I should, but to get access to my data on the machine in question a user would have to hack root and break out of a chroot environment while working in a highly restricted environment with no daemon processes running as root, root logins disabled except for console, and a very restricted set of suid-root binaries installed. Also the kernel in question has a patch applied intended to provide additional isolation between processes associated with different servers, which may make this even more tricky.
I suspect hacking root on this system is very difficult.
If you're THAT concerned about this issue, I assume you're going to call up your ISP and transition your site onto dedicated machines?
My site is low volume. A dedicated machine with similar performance and uptime guarantees would cost somewhere in the region of £200 extra per month, which is a very sizeable chunk of its profits. If I had to carry this cost, I would abandon the business as not worth running.
In any case, I'm not sure I get your distinction between objects as code vs. user interface level features. OLE is code. An ActiveX object is implemented as code but it generally has a UI. Is a Java Bean a user interface level feature? How about an EJB? Are you saying that "the idea of a button is a user interface level object, but a JButton is a code level object?".
Effectively, yes. What I see here is a patent on a specific type of interaction which doesn't really refer to implementation details, except in passing. The core of the patent is about how the user can interact with the e-mail addresses, not how the program is organised to achieve this effect.
Which is even worse than an implementation detail patent, IMO. The software industry tried to protect 'look and feel' through copyright in the 80s, and failed. Now they're trying to do it through patents, instead. And they might succeed.
People will get in through a simple sploit as always and then use a local root sploit as always. getting there is easier than this attack and once you are there you can just read the rsa key file, or read it from another processes instead of trying to guess what it is from cache behaviours.
That depends on such an exploit being available. There isn't always a known way of achieving this in any given system. For instance, do you know any way on a stock Linux system (let's say kernel 2.4.29) of breaking out of a chroot environment? I don't know that it can't be done, but my suspicion is that it's probably quite hard.
This exploit, also, is quite hard. But even exploits like this can be automated, and I don't find it too improbable that kits aimed at grabbing keys from specific pieces of software might start becoming available, do you? And once such kits are available, then the difficulty of the exploit is not going to put anyone off.
You would think that in a legal document like this if they meant OLE they would have said OLE.
Patents are often left intentionally ambiguous, so that they can later claim that something slightly outside what they were originally intending is covered by it. They said something that might be construed to mean OLE, or indeed any other mechanism that provides a similar function. It certainly is clear that they were talking about objects as a user interface level feature, not a code level one.
It depends what you mean by 'object'. In this case, the patent is talking in terms of user interface objects, possibly intending reference to other MS technologies like OLE that use the term in a very specific fashion. This is a lot more advanced and specific than the kind of object that you need to use to program in a pure-OO programming language.
The best solution is to just fix the crypto libraries as a short term solution, and for Intel to fix the chip in future iterations as a long term solution.
Fixing the crypto libraries is actually a non-trivial task. There are many of them and ensuring there is no information leakage is very difficult to achieve.
Fixing the chip may well be impossible -- it sounds to me like the only way to prevent this kind of thing from being a problem is to give each thread its own instruction fetch pipeline, dedicated execution units and dedicated cache lines. Which is, in effect, dropping HT altogether and switching to dual cores instead.
Yes, and they keep saying "how much did you give to my campaign?"
Then kick them out and replace them with a new bunch that do care about the ordinary people. One the main points of democracy is to help prevent corruption, but it doesn't work if the people sit back and let it happen.
That's good advice, but many people cannot afford to follow it. Specialist crypto hardware is too expensive for most users, and keeping a PC in a physically secure environment can be difficult and contradictory with other important considerations. There are many thousands of small internet-based businesses who simply cannot afford this level of protection, and must rely on "secure" servers rented from virtual server farms. Fixing problems like this quickly after they are discovered is important to help protect these people.
If you've spent a lot of time working on something, it's obviously important to you. That doesn't mean that it's important to everyone else.
Well, no, however it is important to many people.
I, like many others here, run an e-commerce web site on Linux servers. In my case, my servers are virtual servers shared with other users who I do not have any knowledge of at all.
If the server used HT, it would be possible for one of those other users to run an exploit on the server to crack my e-commerce site's private key. Fortunately it doesn't, but my ISP could upgrade at any time...
Hence, this is an issue that effects me and my customers, and I seriously hope that a fix finds itself into either apache mod_ssl or the mainline Linux kernel PDQ.
This fix would have to modify how the OS handles the cache
Actually, I believe the best fix is to change the scheduler so that it doesn't schedule processes from different users on the same physical CPU at the same time.
It isn't something Intel can fix, except by removing hyperthreading. The fact of the matter is that if you have two processes running simultaneously on the same processor, one of them can determine things about what the other is doing based on how many execution units of what type it seems to have access to, how long data remains in the cache, things like that. It's a fundamental problem that can only be fixed by the OS kernel denying use of hyperthreading to processes that need to be kept separate from one another.
I don't think so. I haven't used this project, but I don't suspect it includes some of the features that are included in this patent's claims, specifically displaying a graphical icon adjacent to e-mail addresses.
It might be that this is an obvious extension of something BBDB does, but that's for a court to decide, unfortunately.
That post was about a different patent, which I haven't read, that concerned automatic completion.
Also, this patent isn't about treating e-mail addresses as 'objects'. That's just a gross oversimplification of what it deals with that has been snagged from the summary. The claims talk about displaying e-mail addresses in a message preview pane with icons attached to them to provide more information and enable the user to manipulate them.
If you look at the article, the patent is on treating an email address as an object.
And if you look at the patent, it's about a user interface that displays icons next to e-mail addresses to give extra information about them (having looked them up in your address book to find that information).
None of these are actually prior art for this patent, which is about a specific user interface for manipulating e-mail addresses. If you can find an application dating from at the latest mid-90s that showed e-mail addresses with an icon that varied according to the results of a database lookup to determine what kind of address it was, that is prior art.
The problem is that while this is an obvious idea, I think MS were actually the first to do it.
While this is funny, it shows that you only read the summary and not the actual patent, which is for displaying e-mail addresses in a particular fashion in the user interface of an e-mail client, that is showing them with adjacent icons that vary according to the type of address and can be manipulated (e.g. via drag and drop), as Outlook does.
Because the USPTO has a right to issue patents, this kind of action could not succeed. My understanding is that the laws that enable them to issue patents do not require them to ascertain that the patent isn't for something ridiculously trivial like this one, therefore they have performed their duty as described in relevant laws and there is nothing anyone can do about it.
Except bring political pressure against it. Have you talked to your political representatives at every possible level of government and asked them to do something about this problem?
Regarding (1), user scripts can't do anything as damaging as chrome (e.g. extensions).
They can snoop on your cookies and passwords. That's damaging enough, as far as I'm concerned.
no major linux distribution includes a JVM in its distribution
Ahem. This is just blatantly wrong. Go here and search for "java-1_4_2" if you don't believe me.
Yes, because:
(1) there ought to be a big warning box with an enforced reading period (like when you install an xpi package) explaining the potential security problems, and
(2) chances are, only power users are going to be playing with this anyway.
Yes!
Simply set up a script that grabs the title and author of the book, looks it up at a selection of free e-book sites (e.g. project gutenberg, baen.com, etc.) and adds a link if it finds it. Et voila!
Many do at present. On firefox, see "Tools/Options/General/Fonts and Colors". You can also use plugins that have existed for ages that override site supplied style sheets.