Of course - if MS they attacked Mono right off it would only hurt NET'a adoption as a whole. It's much better to wait till something becomes popular and entrenched and then attack it. As for the law, unfortunately just because something seems unfair doesn't make it illegal.
And you honestly believe that if the day ever came where some third party implementation of Net was seriously cutting into Microsoft's profits they wouldn't use this? As a corporation they actually have an obligation to their investors to enforce those patents.
As we've seen after the dot com collapse, patent milking is the last resort of a financially troubled company - that's not Microsoft today, but tomorrow who knows. Assuming *any* corporation will just "play nice" is foolishly naive.
Wow, this article's one juicy bunch of overwrought scare-mongering! It makes "Mr. Leaves" out to be some sort of James Bond super-villain, and then goes on to say "leaves" still took a back-seat to Code Red.
Once you peel back all the hyperbolistic prose, "leaves" seems to be just another run-of-the-IRC zombie that exploits PC already infected with Sub7. Numbers from the article itself show that it had nowhere near the infection rate or virulence of Code Red. The strange bit is at the end they imply, once the guy was caught, they just left the zombies out there rather than alert the owners of the infected PCs!? Odd that, wonder what the gov wants with all those waiting worms...
The sad truth is most users understand very little about SSL. I've seen several shady sites avoid the certificate warnings by just out and out lying.
They'll say on the page "This is a secure transaction" and maybe stick up a Verisign logo. In reality they just use plain HTTP all along. Hey-presto: no warnings!:-)
While some users may be turned away by a error message, very, very few every bother to look at the little lock icon or check the URL (which even on legit sites, half the time is redirected starting from a normal HTTP connection).
Again it's simple - the decoder (read player) has a buffer overflow bug. A malicious MP3 is crafted to trigger the bug and force WinAmp to run code hidden within the MP3. This code can then do anything - like infect other MP3s on the system. Lather, rinse, repeat...
Also being read only is no protection. If you can toggle that flag so can a worm or virus. The only protection is if the program with the bug doesn't have authority to change the file at all, but especially under Windows, that's rare. Even under *nix I'd guess it's pretty common to have MP3 files owned by the same user as the player is running under.
And yes, buffer overflows do in fact work *exactly* "like that". Any program that reads and processes any kind of file, could run this risk if it's error checking isn't perfect somewhere. It's when a file error *isn't* caught (and causes a crash) that the trouble starts. If the program noticed there was something odd with the file, the bug probably wouldn't happen in the first place. Programs that read binary files (like MP3s) tend to be more vunerable - mostly because processing them is far more complex and there's more potential for an error to slip through the cracks.
It's very possible if there's a buffer overflow condition in the decoder. In that case the MP3 player doesn't just "skip it". An overflow can cause the data to be written over-top of parts of the running program's code. Normally this just causes a crash, but if carefully designed, the overflow can be used to inject in exploit code instead. From that point on, the program is running altered code and you may never be aware anything's happened.
Actually the idea, at least, is more credible than you think. Unlike reading a text file, decompressing an mp3 involves lot of complex code. A buffer overrun anywhere in that process could quite possibly be used to infect a system (though so far most have only been in the ID3 tags).
Under windows especially, most players are really just GUI shells and use the same codecs to do the real work. If, for instance, the MP3 codec Microsoft uses had a vulnerability, wide-spread infection would be pretty easy. Makes me wonder if there's a way to use Lame for the default MP3 playback under windows (I know there's a DirectShow encoder out there).
Bull - no normal consmer grade microwave would. Any microwave that could "evaporate" an arm's worth of flesh in 30 seconds would instantly burn most foods to a crisp too. It's a microwave not a reactor core.
Yeah right. Where do people get this stuff? Most microwaves can't even heat up a ham sandwich in 30 seconds let alone "evaporate all the tissues on your arm". Just bringing a cup of water to a boil takes several minutes after all.
Bandwidth and other resources - that's what. It's easy to send millions of emails, but quite costly to process millions of inbound confirms. They'd have to personally deal with the flood of traffic they create. Plus, they'd have to supply a valid return address.
The one obvious method would be for the spammer to add something random to every mail sent. Actually many already do this, so a simple hash wouldn't be enough. You'd need some sort of fuzzy match to detect similar, but not identical, emails.
I think this is a good point. Almost *any* confirmation based whitelist - even one that's trivial to automate a reply to - should work.
In fact, you could even make the reply standard so email clients *could* automate it. That makes it easy for the user, but it would still stop most spammers. Why? Simple...
1) They'd have to supply a valid, working contact address (no more forged headers).
2) It's easier to send millions of emails then receive them. Processing all those confirms would take tons of bandwidth and hefty mail servers. This makes it *much* more expensive for a spammer than just CC'ing a bunch of addresses. Plus, the more spam they send, the more costly it becomes - would likely make the whole business unprofitable.
Yes it should be, but those middlemen have been busy buying off lawmakers to see that this never happens.;-) The common good doesn't even factor into it as long as corporate special interests are keen to keep their gravy-train on track.
Yes because we all know how much movie pirates care about quality! They aren't likely to put any more effort into it then they have to, and camcorders are easy, if crappy, way to rip a movie. If forced to do something more elaborate, it might actually be better quality too!
Heh, it may work for a bit, but if they don't pay, people will just abandon the affiliate program altogether. Kind of defeats the whole reson to have it in the first place - which is to increase exposure and draw in more customers.
You don't need two DVD players as long as you're careful about which one you buy. Region checking is usually done two places: first is in the DVD playback software (PowerDVD, WinDVD, etc), but you can use something like "DVD Genie" to get around that. The second is if the DVD player is RPC2 enabled then the hardware itself will check. However, many RPC2 players have a utility available to turn the protection off. As with all things, just doing a little research with Google before you buy is a good idea.
You're missing the "and then afterwards attempt to illegally access the network" part. They're *not* blacklisting anyone who just downloads one of the fake MP3s - they're blacklisting only those that attempt an attack on the honeypot IPs after doing so. I think they're probably watching for stuff like port scans that they might otherwise ignore.
Same way your computer's TCP/IP stack does. If they can get at the data, the TCP/IP headers will make it easy enough to sort out. Not that it's worth worrying about - there's many easier ways to sniff out network data.
Re:Nevermind Open Relays Old Version of Formmail
on
Spam Slows AT&T Email
·
· Score: 1
This is *very* common nowdays. We get hit by this too, but our version of formmail.pl isn't what it seems. It doesn't actually send any mail at all, but does log everything (including all HTTP headers) to a file. It also generates abuse complaints if an IP contacts it over 10 times (it doesn't actually mail them, but places abuse reports in a file I can check).
Usually you'll see relay "test" attempts on the script first, but if it looks like a spammer, I'll sometimes "forward" these manually.;-)
I figure it's better a spammer send us thousands of messages to nowhere than do the same to a script that's still exploitable (and it makes for a nice weblog to send their ISP!).
The problem with forcing stuff into a pre-defined address space is you'll have peers connected to each other based on a purely arbitrary notion without regard to actual network speeds or conditions. I don't want to find myself connected to some slow dial-up half a world away just because it happens to have a similar address.
Peers should seek other peers based on the quality and better connected peers should automatically move to the center of things. FastTrack works quite well, and it only has one layer of organization (regular vs. supernodes). It might be better to use nature as an example and have some simple set of rules peers would follow to naturally find the best spot for whatever they're doing (the old "ant" idea). You could factor in things like bandwidth, how many searches produced good results, how much overhead traffic is being generated, file types shared, etc. Peers would then keep or drop connections based on these factors. The goal being for each to find its ideal spot. Not just for connectivity, but productivity. Peers with similar searches and files could naturally group together making it easier to find the files you actually care about.
A simple approach to the IP address issue would be for each peer to generate a GUID and use this like a dynamic DNS name (similar to your 64bit idea but less chance of collision). You could then find another peer even when it re-connected under a different IP and more intelligent routing could be set up.
When I see a spammer "testing" our faux formmail.pl script (it's NOT the original), sometimes I'll "forward" it manually. The script we have actually does nothing but log to a file. It's fun to see them sending hundereds of posts to nowhere and generating a nice weblog for me to give to their ISP's abuse department!
I guess I just need to be sure I don't do this to a blackhole list test!;-)
Actually it did have more colors. Like most Atari stuff you had a larger pallet than you could normally show at once, but using hsync interrupts you could get around that somewhat (raster effects). That's why you often see those odd looking line gradients on the sides of the screen in old atari 2600 games.
Slashdot Mirror
Of course - if MS they attacked Mono right off it would only hurt NET'a adoption as a whole. It's much better to wait till something becomes popular and entrenched and then attack it. As for the law, unfortunately just because something seems unfair doesn't make it illegal.
And you honestly believe that if the day ever came where some third party implementation of Net was seriously cutting into Microsoft's profits they wouldn't use this? As a corporation they actually have an obligation to their investors to enforce those patents.
As we've seen after the dot com collapse, patent milking is the last resort of a financially troubled company - that's not Microsoft today, but tomorrow who knows. Assuming *any* corporation will just "play nice" is foolishly naive.
Wow, this article's one juicy bunch of overwrought scare-mongering! It makes "Mr. Leaves" out to be some sort of James Bond super-villain, and then goes on to say "leaves" still took a back-seat to Code Red.
Once you peel back all the hyperbolistic prose, "leaves" seems to be just another run-of-the-IRC zombie that exploits PC already infected with Sub7. Numbers from the article itself show that it had nowhere near the infection rate or virulence of Code Red. The strange bit is at the end they imply, once the guy was caught, they just left the zombies out there rather than alert the owners of the infected PCs!? Odd that, wonder what the gov wants with all those waiting worms...
The sad truth is most users understand very little about SSL. I've seen several shady sites avoid the certificate warnings by just out and out lying.
:-)
They'll say on the page "This is a secure transaction" and maybe stick up a Verisign logo. In reality they just use plain HTTP all along. Hey-presto: no warnings!
While some users may be turned away by a error message, very, very few every bother to look at the little lock icon or check the URL (which even on legit sites, half the time is redirected starting from a normal HTTP connection).
Again it's simple - the decoder (read player) has a buffer overflow bug. A malicious MP3 is crafted to trigger the bug and force WinAmp to run code hidden within the MP3. This code can then do anything - like infect other MP3s on the system. Lather, rinse, repeat...
Also being read only is no protection. If you can toggle that flag so can a worm or virus. The only protection is if the program with the bug doesn't have authority to change the file at all, but especially under Windows, that's rare. Even under *nix I'd guess it's pretty common to have MP3 files owned by the same user as the player is running under.
And yes, buffer overflows do in fact work *exactly* "like that". Any program that reads and processes any kind of file, could run this risk if it's error checking isn't perfect somewhere. It's when a file error *isn't* caught (and causes a crash) that the trouble starts. If the program noticed there was something odd with the file, the bug probably wouldn't happen in the first place. Programs that read binary files (like MP3s) tend to be more vunerable - mostly because processing them is far more complex and there's more potential for an error to slip through the cracks.
Oh? did he really?
It's very possible if there's a buffer overflow condition in the decoder. In that case the MP3 player doesn't just "skip it". An overflow can cause the data to be written over-top of parts of the running program's code. Normally this just causes a crash, but if carefully designed, the overflow can be used to inject in exploit code instead. From that point on, the program is running altered code and you may never be aware anything's happened.
Actually the idea, at least, is more credible than you think. Unlike reading a text file, decompressing an mp3 involves lot of complex code. A buffer overrun anywhere in that process could quite possibly be used to infect a system (though so far most have only been in the ID3 tags).
Under windows especially, most players are really just GUI shells and use the same codecs to do the real work. If, for instance, the MP3 codec Microsoft uses had a vulnerability, wide-spread infection would be pretty easy. Makes me wonder if there's a way to use Lame for the default MP3 playback under windows (I know there's a DirectShow encoder out there).
Bull - no normal consmer grade microwave would. Any microwave that could "evaporate" an arm's worth of flesh in 30 seconds would instantly burn most foods to a crisp too. It's a microwave not a reactor core.
Yeah right. Where do people get this stuff? Most microwaves can't even heat up a ham sandwich in 30 seconds let alone "evaporate all the tissues on your arm". Just bringing a cup of water to a boil takes several minutes after all.
Bandwidth and other resources - that's what. It's easy to send millions of emails, but quite costly to process millions of inbound confirms. They'd have to personally deal with the flood of traffic they create. Plus, they'd have to supply a valid return address.
The one obvious method would be for the spammer to add something random to every mail sent. Actually many already do this, so a simple hash wouldn't be enough. You'd need some sort of fuzzy match to detect similar, but not identical, emails.
I think this is a good point. Almost *any* confirmation based whitelist - even one that's trivial to automate a reply to - should work.
In fact, you could even make the reply standard so email clients *could* automate it. That makes it easy for the user, but it would still stop most spammers. Why? Simple...
1) They'd have to supply a valid, working contact address (no more forged headers).
2) It's easier to send millions of emails then receive them. Processing all those confirms would take tons of bandwidth and hefty mail servers.
This makes it *much* more expensive for a spammer than just CC'ing a bunch of addresses. Plus, the more spam they send, the more costly it becomes - would likely make the whole business unprofitable.
Yes it should be, but those middlemen have been busy buying off lawmakers to see that this never happens. ;-) The common good doesn't even factor into it as long as corporate special interests are keen to keep their gravy-train on track.
Yes because we all know how much movie pirates care about quality! They aren't likely to put any more effort into it then they have to, and camcorders are easy, if crappy, way to rip a movie. If forced to do something more elaborate, it might actually be better quality too!
May help a bit, but I'm sure many of the customers ISP's use Worldnet for their backbone too.
Heh, it may work for a bit, but if they don't pay, people will just abandon the affiliate program altogether. Kind of defeats the whole reson to have it in the first place - which is to increase exposure and draw in more customers.
You don't need two DVD players as long as you're careful about which one you buy. Region checking is usually done two places: first is in the DVD playback software (PowerDVD, WinDVD, etc), but you can use something like "DVD Genie" to get around that. The second is if the DVD player is RPC2 enabled then the hardware itself will check. However, many RPC2 players have a utility available to turn the protection off. As with all things, just doing a little research with Google before you buy is a good idea.
You're missing the "and then afterwards attempt to illegally access the network" part. They're *not* blacklisting anyone who just downloads one of the fake MP3s - they're blacklisting only those that attempt an attack on the honeypot IPs after doing so. I think they're probably watching for stuff like port scans that they might otherwise ignore.
It's a description of badtrans not klez.
Same way your computer's TCP/IP stack does. If they can get at the data, the TCP/IP headers will make it easy enough to sort out. Not that it's worth worrying about - there's many easier ways to sniff out network data.
This is *very* common nowdays. We get hit by this too, but our version of formmail.pl isn't what it seems. It doesn't actually send any mail at all, but does log everything (including all HTTP headers) to a file. It also generates abuse complaints if an IP contacts it over 10 times (it doesn't actually mail them, but places abuse reports in a file I can check).
;-)
Usually you'll see relay "test" attempts on the script first, but if it looks like a spammer, I'll sometimes "forward" these manually.
I figure it's better a spammer send us thousands of messages to nowhere than do the same to a script that's still exploitable (and it makes for a nice weblog to send their ISP!).
The problem with forcing stuff into a pre-defined address space is you'll have peers connected to each other based on a purely arbitrary notion without regard to actual network speeds or conditions. I don't want to find myself connected to some slow dial-up half a world away just because it happens to have a similar address.
Peers should seek other peers based on the quality and better connected peers should automatically move to the center of things. FastTrack works quite well, and it only has one layer of organization (regular vs. supernodes). It might be better to use nature as an example and have some simple set of rules peers would follow to naturally find the best spot for whatever they're doing (the old "ant" idea). You could factor in things like bandwidth, how many searches produced good results, how much overhead traffic is being generated, file types shared, etc. Peers would then keep or drop connections based on these factors. The goal being for each to find its ideal spot. Not just for connectivity, but productivity. Peers with similar searches and files could naturally group together making it easier to find the files you actually care about.
A simple approach to the IP address issue would be for each peer to generate a GUID and use this like a dynamic DNS name (similar to your 64bit idea but less chance of collision). You could then find another peer even when it re-connected under a different IP and more intelligent routing could be set up.
When I see a spammer "testing" our faux formmail.pl script (it's NOT the original), sometimes I'll "forward" it manually. The script we have actually does nothing but log to a file. It's fun to see them sending hundereds of posts to nowhere and generating a nice weblog for me to give to their ISP's abuse department!
;-)
I guess I just need to be sure I don't do this to a blackhole list test!
Actually it did have more colors. Like most Atari stuff you had a larger pallet than you could normally show at once, but using hsync interrupts you could get around that somewhat (raster effects). That's why you often see those odd looking line gradients on the sides of the screen in old atari 2600 games.