Other than extra CPU requirements, are there any issues with this approach?
Depends on how you look at it, and what you are trying to protect against. In most cases combining two hashes in that way will produce something that can be attacked faster than brute force. You'd get better security with a hash function that was designed to be 288 bits in the first place. (Or even 256 bits). In fact even if the two hashes had no weaknesses at all, you could still produce a collision for the concatenation slightly slower than an attack against the strongest of the two.
An attack could work the following way. Produce a collision for the first block of sha1 (2^80 work using birthday attack, I think there might be faster ways). Take the output IV and repeat the attack for the next block. You are going to need about 64 blocks in total. That is 2^86 work. Now run through all combinations of your blocks to find a collision for md5 (that amount of work is nothing compared to the previous work). So this combined hash can be attacked in 2^86 work not 2^144 like you would expect from a 288 bit hash.
After having read the actual article I realize that there in fact is something new in it. The slashdot story put all the focus on software signing, which is not the interesting part of the article. The interesting part of the article is, that they have found a new and stronger way to produce collisions. For one thing it is going to be a lot less obvious that a file is crafted. The original attack required all the colliding files to contain all the meaningful content with some psuedorandom content to select between them. The new attack doesn't require this, in fact you could even produce collisions beteween files of different formats. Like a jpg file and an exe file with the same md5 hash. But still it is just a collision attack, it produces collisions between two crafted files. They don't produce collisions between a collision between an arbitrary original file and one crafted file.
As others have pointed out, there is nothing new in this. The same has been demonstrated with other languages before. For example a few years ago it was demonstrated with postscript, and that was as far as I know the first demonstration with meaningful content. While that may have come as a surprise to some people, it was only a minor curiosity to people understanding how md5 works. Doing this thing with exe files is less significant than it was to do it with postscript files for the following reason. You are not likely to sign an exe file from an untrusted source, because there is no way to verify if the content is malicious, and most people know this. In fact that is the very reason for having signatures in the first place. With postscript files it is different, to most people a postscript file is just a document. With a document you can read it, and then you know exactly what the content is. At least I can understand why people would think that way. So less social engineering is required to get your crafted postscript file signed than it would to get a crafted exe file signed. If you can get somebody to sign your carefully crafted exe file, then this attack doesn't matter anyway. Because if you could get your malicious code into the signed executable, there are lots of other ways to trigger it. Having an interchangable piece of pseudorandom binary data in the file itself is a neat way to trigger your code. But it can be based on other external factors such as timing, the IP address of the machine, the existence of certain other files on the system, or just some secret sequence of inputs. It is all just the matter of putting a backdoor into a piece of code, and attacking md5 in this way is not even the most convenient backdoor you could make.
If it was possible to make a crafted file that would match the md5 of some existing file, which you had no control over, then there would be a lot more reason to worry. Luckily that is not the case yet. Still the demonstration of collisions does serve as a warning, that md5 is weak and maybe somebody will be able to completely break it at some point. There has been a reason to worry about that ever since the collisions were first demonstrated. The construction of additional collisions with meaningful content doesn't change that threat in any way. If you were not worried before this news but you are worried afterwards, it is because you didn't understand the threat.
it was single-tasking so you could just use whatever memory you wanted to.
That is not the reason. Yes it was essentially single tasking, but that didn't prevent you from having multiple programs in memory at once. But only one could be active at a time, and process control worked like a stack. But even though the other programs in memory were not running, there would still be memory belonging to somebody other than you, and some of them might even be providing some kind of service which you were relying on. So DOS in fact had to implement a full blown memory management. Of course since there were no protection you could write outside the memory allocated to you, the result would most likely be that you crashed the system. Ownership of memory was of course made a bit tricky by the fact that you could just allocate a chunk and leave it around when terminating, sometimes you would even do that on intention.
Multi tasking and protection are not that much tied to each other, you can implement the one without the other. But a modern operating system have both.
Normally I'd talk to a lawyer, perhaps your labor union have some that would help you. But for this particular case the terms are so outrageous, that I don't need a lawyer to decide not to sign that contract. You cannot just go get a new job after that, because there would be a conflict between this contract and your new employment contract. And good luck with getting a new job if you tell your future employer about this contract. Where a lawyer could come into the pictuer is:
To give you advice on whether this contract would be binding if you signed it. (But I wouldn't want to play that game even if a lawyer told me it was safe).
To give advice on exactly what amount of changes is needed to the contract before it is acceptable, and how much you should expect to get in return.
Of course if the company would pay your salaray for those six months, it may be acceptable. Just make sure it is paid ahead, and your obligations under the contract are terminated if they don't pay on time.
Why on earth would you tell your current employer where you are going next?
When I last changed job, I told that to my previous employer. I did that because of the anticompetitive clause in my contract. For the duration of that clause I was entitled to a compensation, that was depending on my income. So I had to give them some amount of information. I thought I might as well tell them were I was going, I did so both verbally and in writing. Besides I didn't really have any reason to hide it. I would tell my friends and family where I was going to work, why not also my collegaues at the time?
The timeline which is being linked to starts in 2006. But it is still not too late to get started developing a new algorithm, the submission deadline is a year from now. I guess people with the required skills have probably known about it for a while though, so anybody who intend to submit something is probably already working on it.
That is a relevant point. I'm occationally on call, and I have a cell phone for that purpose.
Oh, and a different point. When I read this story on slashdot I was actually doing it on my cellphone from a restaurant. Was I disturbing anybody? Surely not, I was the most quiet person in that room. Why should I not be allowed to read slashdot while waiting for my food?
I can think of decent technical solutions for this problem. How about having a special base station inside the quiet area. That base station would have to know it is special and behave as such. For phones supporting it, the base station can inform them that they are in a quiet area, and they would automatically switch to quiet with vibrator only. The base station would allow communication, but have certain restrictions on voice (and video) calls. It will not allow you to make calls except for emergency numbers. It will allow you to receive calls, but if you answer the phone before leaving the quiet zone, a voice will tell you to leave the quiet zone. In the meantime the caller will get a voice explaining that the person they called are in a quiet zone, and they will have to wait a moment while that person leaves the quiet zone. The restrictions on voice calls can be implemented in a way that doesn't require support from the phone. At the same time data and SMS can be allowed through.
some random lunatic saw a crying woman in a parking lot, killed her, drove her 1000 miles away, and buried her in a shallow grave. Heck, we've all done that once or twice.
I for one have never done that, neither do I think that any significant percentage of the population have ever done that. But maybe that is because I'm not a lunatic, I do occationally wonder if most people are.
Red Hat is also a creator of a significant body of GPL code
And in that area, they do have a choice. For all those GPL components where Red Hat owns the copyright, they could decide to change future versions to a different license. So far they haven't done this, and I don't think they are going to. I can think of a few reasons why Red Hat would not close those components:
There might be small parts of the code which is not owned by Red Hat.
They might think the improvements that other parties can make to the code is more valuable to Red Hat than the few customers they could lose because of CentOS.
There might be Red Hat customers who actually wants those parts to be GPL and would find a different distribution if they were closed.
Closing some components of Red Hat might piss off some of their own developers.
That is one theory. Is that theory more or less likely to be true than the theory that Hans murdered her? I don't know. There is evidence pointing in each direction. If she is alive, Russia must be the most likely place for her to be right now.
But is the police in Russia actually going to look for her? And if she is there, did she do anything criminal by not letting the world know that she is alive?
A very good use of these folks' time would be to reach some milestones on the Linux driver API so that the dang thing will stop changing all the time.
This has been discussed over and over again, and I rarely see anything new being brought into the discussion. If the kernel's internal APIs could never be changed, they could never be improved.
I actually have one point to bring up, which I haven't seen mentioned before. The most frequently seen argument for keeping the internal kernel interfaces fixed is such that hardware vendors can create a driver and never touch it again, and keep that as a binary only driver outside of the kernel tree. The obvious problem with that approach is, that this is not how Linux is supposed to work. Now let's for a moment try to turn this argument around. Why is it acceptable, that those hardware vendors keeps producing new hardware components, which each are doing essentially the same thing, but every generation have a new interface? To me it seems like the interface between driver and kernel is in fact more stable than the interface between driver and hardware. Each vendor keeps producing new interfaces which have nothing in common between vendors or between generations. I'm pretty sure the number of different ways for a driver to talk to a wifi chip is larger than the number of different ways to talk to the kernel across all versions.
The source code is on my web site, but the users are, well, USERS, so when a new kernel release breaks it they just chuck it back at me to fix.
That is nice to hear. Is it under GPL such that it could be integrated into the kernel tree, if somebody wanted to do that?
I won't bother submitting this driver to the free driver project because it's kind of useless without the $3000 piece of hardware it works with (and that's not counting the crates full of minicomputer hardware needed for testing).
If all of the driver code is written already and it just needs to be made part of the kernel tree, it may be worth submitting it anyway.
OK so I'm still stinging from udev. Sure, it's cute. But it required driver hacking (yet again) *and* broke my user-mode application by changing some of the device names.
I agree that change was not handled in the optimal way. The problems with changing device names does come as a bit of surprise to me. I was under the impression that both the old and the new system gave you enough control over the device names, that you shouldn't have had such problems. And I don't recall having had such problems myself. Of course in many programs this can be configured, so I would have been able to just update the config and forget about it.
I'm still interested in hearing how this became a problem for your users. How did they end up with a kernel with which your program did not work? Did they try it with a distribution which you had not tested the software with? Or did the problem show up when they installed an updated kernel on a system that had previously been working? Unless you are using some bleeding edge distribution, updating the kernel shouldn't cause such changes.
And once you knew about the problem and the fix, what did you do to inform your users about it? It shouldn't be much work to put the relevant information on your webpage.
I wouldn't be surprised if this issue ending up being so that nobody would sell you a computer before you have signed an agreement stating that you agree w/having Windows etc. in there.
That would be awesome. I'm sure that would make some customers actually think before they buy the thing. And there would be shops that decide to grab those customers that don't want to be bothered with signing stupid contracts. (Of course I don't know how large a part of the population think before they sign a contract, I certainly hope it is more than 50%).
one of the essential WTO treaties specifies a minimum copyright term of 50 years PMA.
Just because somebody once upon of time made a stupid decission, it doesn't mean that can never be changed. WTO could change that treaty. Or some country powerfull enough to say screw the WTO, could change their copyright to something sensible (in the order of 15-25 years). To me the real question is, whether there is a country that is powerfull enough to say screw those industry lobyists. Yes there are some people who make money from the current copyright situation, but society as a whole does not make any more from the absurdly long copyrights. Time to take one step back and ask yourself why was copyright introduced in the first place. If we hadn't had copyright for the last many years, would politicians have wanted to introduce copyright today. In general I'd say introducing a new law just so some industry can make more money is a bad idea, there ought to be a better reason, if somebody making more money is an unavoidable side effect, then I guess that is not so bad. As an example assume somebody invented some new security equipment for high speed trains, and a law was made requiring it on all new trains. That law makes sense, the company producing the equipment would obviously make more money, but that is not the purpose of the law. But you would politicians listen to lobyists from the leather industry suggesting, that all such trains should be required to have leather seats?
usually the life of the person creating the trust, plus 18 or 21 years (figuring that's the longest possible time that it would take for their youngest-possible direct heir to reach majority).
That argumentation does make a bit of sense (you'd have to add 9 months, but that is just a minor detail). But even though I see the point in that argumentation, I do feel a problem in that approach. At least for copyright, I would much rather it was a fixed period. A fixed period of say 25 years from when the work is created would still be sufficient time to monetize the work.
Now, if you're claiming that the Company will sue everyone over using or distributing the gpl'd version...
A company, which have been named too many times already, have been doing something similar for the last handfull of years but recently went bankrupt. I predict if another company come up with a similar strategy, we will see a similar outcome.
But unofficial patches for closed source software have a worse track record. I recall some other case where IE had a tiny little information leak. Somebody then released a "patch" for that, which not only was an ugly hack, but at the same time introduced a buffer overflow which was a lot worse than the original bug. The "patch" came with source, but AFAIR the license did not permit you to fix the bug in the "patch".
Introducing a much worse security hole when fixing a minor security hole is the kind of thing that can happen when you write code without getting it reviewed. Any decent code review would have caught that bug. And that is not the real reason third party "patches" for closed source software is a bad idea.
The correct way to fix a bug in any piece of software is to take the source, fix the bug, and recompile. No third party can do that for a closed source product, which is why that approach is never going to be good for the users.
You can cut off the end user, but if that end user's machine is part of a botnet, then how much good does that do?
If this was something that ISPs would do consistently, I think it would make people more careful. And if somebody were actually liable for the resources spend by the ISPs finding and disconnecting bots, then it would be feasible to disconnect most of the bots in a botnet. Of course completely disconnecting would not be necesarry, it could be put in a sandbox with access to a "transparent" proxy, that would still allow it to download cleaning tools and security updates (not that I believe you can reliably clean a compromised machine, but it may work sometimes). They just need to prevent the machine from sending spam.
An alternative to the sandbox would be for an ISP to just flag all packets from compromised machines, then the recipient can decide whether they want to accept traffic from compromised machines. If you have a download service with security updates or you provide a service to clean compromised machines, you would obviously want to allow the packets. If you run a mail server and want to prevent spam, you would not allow compromised machines to connect to your port 25. I think the security bit defined in RFC 3514 could be used for this purpose.
That user doesn't have clue who sent spam from his machine.
True, and nobody may ever be able to find out. Finding out who did it is not the most important, it is much more important to learn how to stop it and preventing it from happening again.
Then what does he do about it? You or I can clean or re-image the box, but your average joe with an email account is not going to find that easy
The solution will show up once enough people have the problem. I could provide people with the necesarry help on managing their machine if they run Linux, but currently I don't see enough demand, that I could do it for a living. I couldn't provide much help to users of other operating systems, but there are probably other people who can. I seriously think that people who does not have the abilities to be system administrator of their own computer should buy that support elsewhere, an ISP could sell it as an optional extra service along with an Internet connection. An environment where a capable system administrator is a requirement would create a demand for operating systems that are so easy to administrate, that the average home user is capable of doing so.
the odds he will fix the vulnerability that caused him to get compromised in the first place are really low
In many cases it is just a matter of upgrading the vulnurable software to the latest version, in which the bug has been fixed. How often is it really the case that bots are compromised through vulnurabilities for which there is no fix? Would only happen if the bug was not known by the softare vendor, or if the software vendor decided not to fix it. Of course a machine can also be compromised due to user error. I don't want to get into an argument about whether that is because the user is stupid or because the software is too difficult to use.
The disk is literally unusable without the password.
I consider that to be a design flaw. It should be possible to change the password without knowing the old one, but of course doing so would mean all data on the disk were lost. But are you really sure the disk encrypted the data? And could you verify the quality of the encryption? Maybe flashing a new firmware on the drive would have allowed you to bypass the protection.
I predict the spam percentage will keep growing as long as no ISP is willing to spend the resources it takes to stop it. Companies, who think they can make money from fighting spam are never going to help. Rather it is companies that provide other services (such as email), who have to start understanding their obligation to spend some of their income on fighting the abuse that could be done through their service.
First of all when you sign up for a connection, the contract should state, that you are not allowed to send spam, and you are liable for the cost to track you down, if you do. It could be done by paying some reasonable deposit when signing up. And when ISPs make peering agreements, responsibility to track down the origin of spam has to be part of the agreement. If ISPs were willing to operate this way, it would just require one recipient of a spam message to contact his own ISP about it, and the source of that mail would be tracked down and disconnected from the net. (Same solution could be used for flooding and IP spoofing, which are also things that can only be stopped at the source).
It just ain't gonna happen. Because end users don't understand how it works. And as long as end users don't understand, they are going to choose the cheapest provider, which is the one who does not spend resources on fighting spam. Oh, maybe they have a socalled spam filter, which based on some heuristics throws away some of the messages to their own customers, and the customers will be happy (and blame the sender of messages, when the filter discards legitimate messages).
I feel we are now at the point, where the problems caused by spam filters blocking legitimate email are growing faster than the spam itself. And we will have to witness a total meltdown of the email system, before anybody will grab the problems by the root and solve it.
Because it's a one-to-many mapping. You can have multiple PTR records for a single IP. If I use the same mail server for foo.com and bar.com, then I can set up PTR records pointing to both foo.com and bar.com. If you do a reverse DNS lookup, you will get both. The HELO command lets me pick which one I want to be today.
I think you meant to say many-to-many. Apart from that, I do get your point. Unfortunately, I don't think it is going to work anyway. First of all, the software implementing the checking, which I described, rarely (if ever) supports the scenario where the IP map to multiple hostnames. Rather what happens in a bit more detail is, that first one component does a lookup of the IP and get a hostname. If you tried to give it multiple, it would (depending on the implementation) take either the first or a random. It then passes on the hostname it got from the HELO command and the hostname it got by looking up the IP. Then another component (possibly much later) will compare the two hostnames to see if they are identical. The fact that the IP resolved to multiple hostnames would have been forgotten already, and all it knows about are the two hostnames provided by a component, which had no idea that some later system would expect the two to be identical.
Another problem is, that it is much more common to have multiple hostnames resolve to one IP, but have the IP resolve to just one hostname. And that hostname is often not the one you intend to provide in your HELO command. A much more reliable verification would be to just lookup the hostname provided in the HELO command, and not even bother with using DNS to perform IP to hostname lookups. Of course you could just completely forget about trying to validte the hostname in the HELO command. My experience is, that any attempts at such validation does more harm than good.
Slashdot Mirror
An attack could work the following way. Produce a collision for the first block of sha1 (2^80 work using birthday attack, I think there might be faster ways). Take the output IV and repeat the attack for the next block. You are going to need about 64 blocks in total. That is 2^86 work. Now run through all combinations of your blocks to find a collision for md5 (that amount of work is nothing compared to the previous work). So this combined hash can be attacked in 2^86 work not 2^144 like you would expect from a 288 bit hash.
After having read the actual article I realize that there in fact is something new in it. The slashdot story put all the focus on software signing, which is not the interesting part of the article. The interesting part of the article is, that they have found a new and stronger way to produce collisions. For one thing it is going to be a lot less obvious that a file is crafted. The original attack required all the colliding files to contain all the meaningful content with some psuedorandom content to select between them. The new attack doesn't require this, in fact you could even produce collisions beteween files of different formats. Like a jpg file and an exe file with the same md5 hash. But still it is just a collision attack, it produces collisions between two crafted files. They don't produce collisions between a collision between an arbitrary original file and one crafted file.
As others have pointed out, there is nothing new in this. The same has been demonstrated with other languages before. For example a few years ago it was demonstrated with postscript, and that was as far as I know the first demonstration with meaningful content. While that may have come as a surprise to some people, it was only a minor curiosity to people understanding how md5 works. Doing this thing with exe files is less significant than it was to do it with postscript files for the following reason. You are not likely to sign an exe file from an untrusted source, because there is no way to verify if the content is malicious, and most people know this. In fact that is the very reason for having signatures in the first place. With postscript files it is different, to most people a postscript file is just a document. With a document you can read it, and then you know exactly what the content is. At least I can understand why people would think that way. So less social engineering is required to get your crafted postscript file signed than it would to get a crafted exe file signed. If you can get somebody to sign your carefully crafted exe file, then this attack doesn't matter anyway. Because if you could get your malicious code into the signed executable, there are lots of other ways to trigger it. Having an interchangable piece of pseudorandom binary data in the file itself is a neat way to trigger your code. But it can be based on other external factors such as timing, the IP address of the machine, the existence of certain other files on the system, or just some secret sequence of inputs. It is all just the matter of putting a backdoor into a piece of code, and attacking md5 in this way is not even the most convenient backdoor you could make.
If it was possible to make a crafted file that would match the md5 of some existing file, which you had no control over, then there would be a lot more reason to worry. Luckily that is not the case yet. Still the demonstration of collisions does serve as a warning, that md5 is weak and maybe somebody will be able to completely break it at some point. There has been a reason to worry about that ever since the collisions were first demonstrated. The construction of additional collisions with meaningful content doesn't change that threat in any way. If you were not worried before this news but you are worried afterwards, it is because you didn't understand the threat.
Multi tasking and protection are not that much tied to each other, you can implement the one without the other. But a modern operating system have both.
- To give you advice on whether this contract would be binding if you signed it. (But I wouldn't want to play that game even if a lawyer told me it was safe).
- To give advice on exactly what amount of changes is needed to the contract before it is acceptable, and how much you should expect to get in return.
Of course if the company would pay your salaray for those six months, it may be acceptable. Just make sure it is paid ahead, and your obligations under the contract are terminated if they don't pay on time.The timeline which is being linked to starts in 2006. But it is still not too late to get started developing a new algorithm, the submission deadline is a year from now. I guess people with the required skills have probably known about it for a while though, so anybody who intend to submit something is probably already working on it.
That is a relevant point. I'm occationally on call, and I have a cell phone for that purpose.
Oh, and a different point. When I read this story on slashdot I was actually doing it on my cellphone from a restaurant. Was I disturbing anybody? Surely not, I was the most quiet person in that room. Why should I not be allowed to read slashdot while waiting for my food?
I can think of decent technical solutions for this problem. How about having a special base station inside the quiet area. That base station would have to know it is special and behave as such. For phones supporting it, the base station can inform them that they are in a quiet area, and they would automatically switch to quiet with vibrator only. The base station would allow communication, but have certain restrictions on voice (and video) calls. It will not allow you to make calls except for emergency numbers. It will allow you to receive calls, but if you answer the phone before leaving the quiet zone, a voice will tell you to leave the quiet zone. In the meantime the caller will get a voice explaining that the person they called are in a quiet zone, and they will have to wait a moment while that person leaves the quiet zone. The restrictions on voice calls can be implemented in a way that doesn't require support from the phone. At the same time data and SMS can be allowed through.
That is one theory. Is that theory more or less likely to be true than the theory that Hans murdered her? I don't know. There is evidence pointing in each direction. If she is alive, Russia must be the most likely place for her to be right now.
But is the police in Russia actually going to look for her? And if she is there, did she do anything criminal by not letting the world know that she is alive?
I actually have one point to bring up, which I haven't seen mentioned before. The most frequently seen argument for keeping the internal kernel interfaces fixed is such that hardware vendors can create a driver and never touch it again, and keep that as a binary only driver outside of the kernel tree. The obvious problem with that approach is, that this is not how Linux is supposed to work. Now let's for a moment try to turn this argument around. Why is it acceptable, that those hardware vendors keeps producing new hardware components, which each are doing essentially the same thing, but every generation have a new interface? To me it seems like the interface between driver and kernel is in fact more stable than the interface between driver and hardware. Each vendor keeps producing new interfaces which have nothing in common between vendors or between generations. I'm pretty sure the number of different ways for a driver to talk to a wifi chip is larger than the number of different ways to talk to the kernel across all versions.
That is nice to hear. Is it under GPL such that it could be integrated into the kernel tree, if somebody wanted to do that?
If all of the driver code is written already and it just needs to be made part of the kernel tree, it may be worth submitting it anyway.
I agree that change was not handled in the optimal way. The problems with changing device names does come as a bit of surprise to me. I was under the impression that both the old and the new system gave you enough control over the device names, that you shouldn't have had such problems. And I don't recall having had such problems myself. Of course in many programs this can be configured, so I would have been able to just update the config and forget about it.
I'm still interested in hearing how this became a problem for your users. How did they end up with a kernel with which your program did not work? Did they try it with a distribution which you had not tested the software with? Or did the problem show up when they installed an updated kernel on a system that had previously been working? Unless you are using some bleeding edge distribution, updating the kernel shouldn't cause such changes.
And once you knew about the problem and the fix, what did you do to inform your users about it? It shouldn't be much work to put the relevant information on your webpage.
But unofficial patches for closed source software have a worse track record. I recall some other case where IE had a tiny little information leak. Somebody then released a "patch" for that, which not only was an ugly hack, but at the same time introduced a buffer overflow which was a lot worse than the original bug. The "patch" came with source, but AFAIR the license did not permit you to fix the bug in the "patch".
Introducing a much worse security hole when fixing a minor security hole is the kind of thing that can happen when you write code without getting it reviewed. Any decent code review would have caught that bug. And that is not the real reason third party "patches" for closed source software is a bad idea.
The correct way to fix a bug in any piece of software is to take the source, fix the bug, and recompile. No third party can do that for a closed source product, which is why that approach is never going to be good for the users.
An alternative to the sandbox would be for an ISP to just flag all packets from compromised machines, then the recipient can decide whether they want to accept traffic from compromised machines. If you have a download service with security updates or you provide a service to clean compromised machines, you would obviously want to allow the packets. If you run a mail server and want to prevent spam, you would not allow compromised machines to connect to your port 25. I think the security bit defined in RFC 3514 could be used for this purpose.
True, and nobody may ever be able to find out. Finding out who did it is not the most important, it is much more important to learn how to stop it and preventing it from happening again.
The solution will show up once enough people have the problem. I could provide people with the necesarry help on managing their machine if they run Linux, but currently I don't see enough demand, that I could do it for a living. I couldn't provide much help to users of other operating systems, but there are probably other people who can. I seriously think that people who does not have the abilities to be system administrator of their own computer should buy that support elsewhere, an ISP could sell it as an optional extra service along with an Internet connection. An environment where a capable system administrator is a requirement would create a demand for operating systems that are so easy to administrate, that the average home user is capable of doing so.
In many cases it is just a matter of upgrading the vulnurable software to the latest version, in which the bug has been fixed. How often is it really the case that bots are compromised through vulnurabilities for which there is no fix? Would only happen if the bug was not known by the softare vendor, or if the software vendor decided not to fix it. Of course a machine can also be compromised due to user error. I don't want to get into an argument about whether that is because the user is stupid or because the software is too difficult to use.
I predict the spam percentage will keep growing as long as no ISP is willing to spend the resources it takes to stop it. Companies, who think they can make money from fighting spam are never going to help. Rather it is companies that provide other services (such as email), who have to start understanding their obligation to spend some of their income on fighting the abuse that could be done through their service.
First of all when you sign up for a connection, the contract should state, that you are not allowed to send spam, and you are liable for the cost to track you down, if you do. It could be done by paying some reasonable deposit when signing up. And when ISPs make peering agreements, responsibility to track down the origin of spam has to be part of the agreement. If ISPs were willing to operate this way, it would just require one recipient of a spam message to contact his own ISP about it, and the source of that mail would be tracked down and disconnected from the net. (Same solution could be used for flooding and IP spoofing, which are also things that can only be stopped at the source).
It just ain't gonna happen. Because end users don't understand how it works. And as long as end users don't understand, they are going to choose the cheapest provider, which is the one who does not spend resources on fighting spam. Oh, maybe they have a socalled spam filter, which based on some heuristics throws away some of the messages to their own customers, and the customers will be happy (and blame the sender of messages, when the filter discards legitimate messages).
I feel we are now at the point, where the problems caused by spam filters blocking legitimate email are growing faster than the spam itself. And we will have to witness a total meltdown of the email system, before anybody will grab the problems by the root and solve it.
Another problem is, that it is much more common to have multiple hostnames resolve to one IP, but have the IP resolve to just one hostname. And that hostname is often not the one you intend to provide in your HELO command. A much more reliable verification would be to just lookup the hostname provided in the HELO command, and not even bother with using DNS to perform IP to hostname lookups. Of course you could just completely forget about trying to validte the hostname in the HELO command. My experience is, that any attempts at such validation does more harm than good.