True. However, seeing how noone is learning the damned mistake... Linksys firmware has had the same type of flaw (repeatedly) for a very long time. (In fact, it was how people first got 3rd party firmware on the things.)
The problem is the horrible, lame, stupid practice of using system() with non-sanitized user input. If people would stop using the system() function call -- which many modern compilers will warn you about in the first place -- these problems wouldn't pop up. The example in the alert turns into system("/www/;reboot>/tmp/shellout.asp"). That is so wrong, I'd fail you as a computer science student -- and fire you as an employee.
And no, they did not fix the issue. They turned off (#if 0/#endif) the block of code handling cgi-bin (rev 12532) and then moved the connectivity check (no access via wireless) higher @12533. The bug is still there. a) don't use system(), b) filter out "bad input", and c) start the shell with -e so it will exit on the first error, thus eliminating chaining.
My current static address from AT&T is listed in only one list... MAPS. Despite it being neither dynamic nor "dialup", they refuse to remove it first stating the request must come from the ISP, then stating the ISP explicitly listed the range with them as dynamic (which is a complete lie, as Bellsouth doesn't bother.)
If there's a greater than 90% chance the sender is going to be sending you junk -- which is what RBLs are supposed to tell you, then it's infintely less work to simply tell them to f*** off before they send you anything at all than to receive the entire message, parse it, and then throw it in the trash.
On a Google scale, 90% isn't good enough. But then you have a sufficient volume of messages and direct user reports to build a far better list than all the RBLs combined. For my personal email, that's more than enough -- heck, I deny entire countries.
Fine. Call the "boss" and "sales department", they'll just forward you to me. Even if you manage to get them to listen to your whining, they will never, EVER, come to me and ask to have the "spam filters" turned off. The former CEO learned that lesson the hard way -- to the tune of 100+ messages per hour.
I prefer the "go away" method over the "receive your junk and then throw it away" method. It saves me a lot of bandwidth.
In their words, "it's not extortion as *we* don't see any of the money." It's still bullshit.
I've had issue with them for many years... their "spamtrap" list is 100% untrustable. It only takes one email EVER to get on the list. They provide zero evidence of how you got on the list, just that you are on it. Enties never, ever, expire. And to get off the list... you have to "make a donation." (But if you're google, you get removed without ever knowing you were listed.)
It doesn't work like that. Nodes (eg. your cablemodem) don't talk to each other; they talk to the headend. All traffic has to pass through the headend. DSL can work closer to your ideal, but traffic still has to pass through the DSLAM at the very least -- dsl modems connect to the DSLAM, not each other. However, very few ISPs run their DSL networks like that... every one I've seen trunks everything back to a concentrator.
That's not UAC. What you are talking about is the (simple) difference between a user and an administrator. Microsoft has never understood that difference. Which leads us to the BS that is UAC... even with admin rights you still have to confirm every damned thing you do. It's a horrible stupid kludge. If you don't what people doing "admin" things, don't make them an admin. (it's a tough concept in the windows world.)
Lots of people brew their own beer, etc., completely for personal use. And nobody comes busting down their doors. The stores that sell the necessary equipment and supplies don't ask for licenses or permits.
Farm equipment is generally exempt from fuel taxes. My dad keeps records of the gas put in the tractor to get the road tax back at the end of the year. We used to buy fuel wholesale (sans taxes) but it's not worth the hassle these days. (read: in his old age, his does a lot less farming:-))
I don't know about today, but several years ago a lot of cars not designed to run on alcohol were running on 100% alcohol. The original article's little story of the guy who filled his E85 with E100 and "then it wouldn't work" is guilty of a "lie of omission"... it will indeed run with 100% ethanol, but it's unlikely to be able to start cold with only ethanol. Those Bazilian "converted" cars had a small gasoline tank to get them started, and then it ran completely from ethanol.
(And the "repairs" for that little mistake are absolutely trivial.)
The article mentions an inability (for the "pre-released" version) to PXE boot. If he's talking about booting for installation, then he's 100% wrong. The ESX beta/RC (build 140815) will, indeed, boot and install over a network. It's different from 3.5 so you'll have to adjust your commandline and/or kickstart. They use "weasel" instead of "anaconda" and that runs inside the service console. Short answer... "method=" becomes "url=" -- with a properly formated URL, eg. url=nfs://server/path/to/esx/. It's a much larger boot enviroment -- 80MB -- so it takes longer to boot, and from my half dozen installations (I'm only testing on 2 machines), it takes substantially longer to install 4.0 than 3.5. (my 3.5 installs take 2.5mins.)
This assumes the home has internet connectivity already -- wireless networking, to be specific. The OLPC is rather useless without it. I doubt they will be in high enough densities to form an effective mesh network to the one kid who "has internet."
Personally, I find them slow, lacking in memory, lacking in storage ('tho it does have an SD slot), and the interface sucks. But I'm not a 5yo. When I did put it infront of a 5yo (and 7yo) they played the games on it, and wandered the web (mooching internet from McD's.) I'm still not convinced inflicting "Sugar" on children is such a great idea, but windows is an even worse idea. (imagine how slow it would be with all the anti-whatever software plus windows.)
Broken is broken, sure. But finding two files that generate the same md5 and sha-1 hashes is a much harder nut to crack -- if even remotely possible. I'm not aware of any research into cross hash collisions. I suspect it would be a very remote possibility -- one would need very near complete "boomerang attack"s for both hashes to pull it off. (i.e. knowing what bits to change to keep the hash the same.)
Take for example checksums and crcs. Neither are used in crypto because they are trivial to break. With a checksum, whatever additions are added need to be subtracted elsewhere -- simple. With crc, if you flip one bit, it's easy to know which other bits to flip. CRC's are used in communication systems to detect random bit errors. IP uses simple checksums. Random bit errors can get past a crc or checksum alone, however, it's unlikely to get past both.
MD5 is not SHA-1. True or False? True. MD5 is a 128bit hash. SHA-1 is a 160bit hash. Without any analysis or tricks, MD5 is already much easier to brute force.
You are suggesting the birthday paradox means collisions can be found in 2^26 (2^(n/2)) trys now? That's not what they are saying. They have reduced the work needed to search for a collision ("brute force") from the previously best known 2^57 to 2^52. They have not effectively reduced the hash size to 2^52. Even though that's a marked improvement, it still puts the work beyond the reach of mere mortals.
(And btw, the "birthday attack" is not an "attack". It's just statistics showing the probabilites of collisions at random.)
I know this is hard to grasp, but MD5 is not SHA-1.
By definition, ALL hash functions have collisions; finding any random collision is quite easy (if time consuming.) Put simply, one cannot uniquely represent 4096 bit inputs with 160 bit outputs: 2^4096 is MUCH larger than 2^160. The trick is being able to generate a meaningful document with the same hash as an existing document; that's not at all easy. The only examples I've seen consist of either a single document specifically designed to be altered, or two random, meaningless documents with the same hash. SSL certs fall into the former as they naturally contain a large random section ("key") making them far simpler to tweak. (but that's not saying it can be done in a reasonable time frame with todays technology. however, that day is approaching.)
What the f*** were you driving? An M-1 tank! I fill my car about once a month (approx. every 3 weeks) -- it has a 14gal tank. And my insurance is less than that PER FREAKIN YEAR. For two cars.
(Btw, it costs me less than $1500 per year to drive both of my cars -- but I own them.)
I often want to shoot people who develop code for other people to use and then refuse to even listen to the issues those other people have with said code.
"Yes, your luggage is covered in gasoline, and torn to shreds, but it might have been that way before"
If it was covered in gas (and shreded) at the time it was handed over to be CHECKED, it wouldn't have been accepted -- or are you too stupid to realize there are humans in the process. (and carrying a gas soaked anything into an airport in this country is a good way to not make your flight.) This isn't a matter of a gas covered anything, or children with tire tracks on them. It's a broken fucking laptop. It could have been broken by the airline. It could have been broken by him in transit. It could have been broken when he packed it. But yes, let's immediately assume the airline is at fault because of this guy's stupidity.
Did the airline break it? Maybe (even probablly.) But there's a non-zero probability that he had a broken laptop in there to begin with. (yes, there ARE people who abuse the system.) His post here really makes me suspect that might be the case -- it's a "high performance" laptop that he doesn't need and doesn't care enough about to fix it out of his own pocket. There's no proof of who broke it, so taking the far more expensive route past a judge is an expensive gamble.
Yes, yes. Let's waste our time and money in court costs and lawyers fees to get $200 for a laptop screen out of the airline because you were too much of an idiot to either pack the laptop properly (assuming, as the airline states, it wasn't broken before hand) or carry it with you.
And let's not forget, he doesn't want to spend any of his money on it as he "has other laptops" -- read: "I don't need this laptop."
(disclaimer: He never said anything at all about what that laptop actually is. So the age, value, and repair costs are completely unknown.)
Read the fine print. The airline is not responsible for the damage. Do. Not. Check. Laptops. Carry it with you at all times. Common luggage offers little if any protection for a laptop. Have you ever watched how the baggage handlers "handle" luggage?
What? He doesn't have any form of insurance of his own? The cost of a screen is substantially cheaper than the cost of a new laptop. (unless it's an old and/or crappy laptop.)
I've found most "sysadmin" IT types are not good cable makers -- lack of training, lack of desire, lack of experience (how often does making a cable come up?)... As a "network engineer", I know how to make a cable as well as why it's made that way.
There are lots of reasons a random cable may work at 100m but not 1000m. 1000bT uses all 4 pairs at much higher frequency -- the longer the run, the more important that becomes.
That said, fixing a keystone or patch panel is a lot easier than a bad crimp.
Stop fooling yourself; those mass produced cables are not "pre-tested". They aren't tested at all. I've found plenty that wouldn't pass a continuity test, much less a spectrum test. Give the cables are made faster than they can be tested, the best you can expect is "batch testing".
The only reason to buy premade cables -- in bulk --... TIME. The only time I'll make a batch of cables is when I have very little else to do. (or don't want to wait for a box to arrive.)
Slashdot Mirror
True. However, seeing how noone is learning the damned mistake... Linksys firmware has had the same type of flaw (repeatedly) for a very long time. (In fact, it was how people first got 3rd party firmware on the things.)
The problem is the horrible, lame, stupid practice of using system() with non-sanitized user input. If people would stop using the system() function call -- which many modern compilers will warn you about in the first place -- these problems wouldn't pop up. The example in the alert turns into system("/www/;reboot>/tmp/shellout.asp"). That is so wrong, I'd fail you as a computer science student -- and fire you as an employee.
And no, they did not fix the issue. They turned off (#if 0/#endif) the block of code handling cgi-bin (rev 12532) and then moved the connectivity check (no access via wireless) higher @12533. The bug is still there. a) don't use system(), b) filter out "bad input", and c) start the shell with -e so it will exit on the first error, thus eliminating chaining.
My current static address from AT&T is listed in only one list... MAPS. Despite it being neither dynamic nor "dialup", they refuse to remove it first stating the request must come from the ISP, then stating the ISP explicitly listed the range with them as dynamic (which is a complete lie, as Bellsouth doesn't bother.)
If there's a greater than 90% chance the sender is going to be sending you junk -- which is what RBLs are supposed to tell you, then it's infintely less work to simply tell them to f*** off before they send you anything at all than to receive the entire message, parse it, and then throw it in the trash.
On a Google scale, 90% isn't good enough. But then you have a sufficient volume of messages and direct user reports to build a far better list than all the RBLs combined. For my personal email, that's more than enough -- heck, I deny entire countries.
Clueless, no. Lazy, maybe.
Fine. Call the "boss" and "sales department", they'll just forward you to me. Even if you manage to get them to listen to your whining, they will never, EVER, come to me and ask to have the "spam filters" turned off. The former CEO learned that lesson the hard way -- to the tune of 100+ messages per hour.
I prefer the "go away" method over the "receive your junk and then throw it away" method. It saves me a lot of bandwidth.
In their words, "it's not extortion as *we* don't see any of the money." It's still bullshit.
I've had issue with them for many years... their "spamtrap" list is 100% untrustable. It only takes one email EVER to get on the list. They provide zero evidence of how you got on the list, just that you are on it. Enties never, ever, expire. And to get off the list... you have to "make a donation." (But if you're google, you get removed without ever knowing you were listed.)
It doesn't work like that. Nodes (eg. your cablemodem) don't talk to each other; they talk to the headend. All traffic has to pass through the headend. DSL can work closer to your ideal, but traffic still has to pass through the DSLAM at the very least -- dsl modems connect to the DSLAM, not each other. However, very few ISPs run their DSL networks like that... every one I've seen trunks everything back to a concentrator.
That's not UAC. What you are talking about is the (simple) difference between a user and an administrator. Microsoft has never understood that difference. Which leads us to the BS that is UAC... even with admin rights you still have to confirm every damned thing you do. It's a horrible stupid kludge. If you don't what people doing "admin" things, don't make them an admin. (it's a tough concept in the windows world.)
Lots of people brew their own beer, etc., completely for personal use. And nobody comes busting down their doors. The stores that sell the necessary equipment and supplies don't ask for licenses or permits.
Farm equipment is generally exempt from fuel taxes. My dad keeps records of the gas put in the tractor to get the road tax back at the end of the year. We used to buy fuel wholesale (sans taxes) but it's not worth the hassle these days. (read: in his old age, his does a lot less farming :-))
Actually, they're more interested in you paying the required fuel taxes.
So did I (in NC.) My milage increased. (from 30mpg to 35+mpg. in an '86 Ford Tempo)
I don't know about today, but several years ago a lot of cars not designed to run on alcohol were running on 100% alcohol. The original article's little story of the guy who filled his E85 with E100 and "then it wouldn't work" is guilty of a "lie of omission"... it will indeed run with 100% ethanol, but it's unlikely to be able to start cold with only ethanol. Those Bazilian "converted" cars had a small gasoline tank to get them started, and then it ran completely from ethanol.
(And the "repairs" for that little mistake are absolutely trivial.)
ESX isn't designed to be run "diskless". It has to have somewhere to put it's VMFS -- which in 4.0 also contains swap and a few other things.
(That doesn't mean one cannot bend it into a shape that will run diskless.)
The article mentions an inability (for the "pre-released" version) to PXE boot. If he's talking about booting for installation, then he's 100% wrong. The ESX beta/RC (build 140815) will, indeed, boot and install over a network. It's different from 3.5 so you'll have to adjust your commandline and/or kickstart. They use "weasel" instead of "anaconda" and that runs inside the service console. Short answer... "method=" becomes "url=" -- with a properly formated URL, eg. url=nfs://server/path/to/esx/. It's a much larger boot enviroment -- 80MB -- so it takes longer to boot, and from my half dozen installations (I'm only testing on 2 machines), it takes substantially longer to install 4.0 than 3.5. (my 3.5 installs take 2.5mins.)
One that's trying to cover his own ass.
This assumes the home has internet connectivity already -- wireless networking, to be specific. The OLPC is rather useless without it. I doubt they will be in high enough densities to form an effective mesh network to the one kid who "has internet."
Personally, I find them slow, lacking in memory, lacking in storage ('tho it does have an SD slot), and the interface sucks. But I'm not a 5yo. When I did put it infront of a 5yo (and 7yo) they played the games on it, and wandered the web (mooching internet from McD's.) I'm still not convinced inflicting "Sugar" on children is such a great idea, but windows is an even worse idea. (imagine how slow it would be with all the anti-whatever software plus windows.)
Broken is broken, sure. But finding two files that generate the same md5 and sha-1 hashes is a much harder nut to crack -- if even remotely possible. I'm not aware of any research into cross hash collisions. I suspect it would be a very remote possibility -- one would need very near complete "boomerang attack"s for both hashes to pull it off. (i.e. knowing what bits to change to keep the hash the same.)
Take for example checksums and crcs. Neither are used in crypto because they are trivial to break. With a checksum, whatever additions are added need to be subtracted elsewhere -- simple. With crc, if you flip one bit, it's easy to know which other bits to flip. CRC's are used in communication systems to detect random bit errors. IP uses simple checksums. Random bit errors can get past a crc or checksum alone, however, it's unlikely to get past both.
MD5 is not SHA-1. True or False? True. MD5 is a 128bit hash. SHA-1 is a 160bit hash. Without any analysis or tricks, MD5 is already much easier to brute force.
You are suggesting the birthday paradox means collisions can be found in 2^26 (2^(n/2)) trys now? That's not what they are saying. They have reduced the work needed to search for a collision ("brute force") from the previously best known 2^57 to 2^52. They have not effectively reduced the hash size to 2^52. Even though that's a marked improvement, it still puts the work beyond the reach of mere mortals.
(And btw, the "birthday attack" is not an "attack". It's just statistics showing the probabilites of collisions at random.)
I know this is hard to grasp, but MD5 is not SHA-1.
By definition, ALL hash functions have collisions; finding any random collision is quite easy (if time consuming.) Put simply, one cannot uniquely represent 4096 bit inputs with 160 bit outputs: 2^4096 is MUCH larger than 2^160. The trick is being able to generate a meaningful document with the same hash as an existing document; that's not at all easy. The only examples I've seen consist of either a single document specifically designed to be altered, or two random, meaningless documents with the same hash. SSL certs fall into the former as they naturally contain a large random section ("key") making them far simpler to tweak. (but that's not saying it can be done in a reasonable time frame with todays technology. however, that day is approaching.)
What the f*** were you driving? An M-1 tank! I fill my car about once a month (approx. every 3 weeks) -- it has a 14gal tank. And my insurance is less than that PER FREAKIN YEAR. For two cars.
(Btw, it costs me less than $1500 per year to drive both of my cars -- but I own them.)
It's only a bug if it effects him.
I often want to shoot people who develop code for other people to use and then refuse to even listen to the issues those other people have with said code.
"Yes, your luggage is covered in gasoline, and torn to shreds, but it might have been that way before"
If it was covered in gas (and shreded) at the time it was handed over to be CHECKED, it wouldn't have been accepted -- or are you too stupid to realize there are humans in the process. (and carrying a gas soaked anything into an airport in this country is a good way to not make your flight.) This isn't a matter of a gas covered anything, or children with tire tracks on them. It's a broken fucking laptop. It could have been broken by the airline. It could have been broken by him in transit. It could have been broken when he packed it. But yes, let's immediately assume the airline is at fault because of this guy's stupidity.
Did the airline break it? Maybe (even probablly.) But there's a non-zero probability that he had a broken laptop in there to begin with. (yes, there ARE people who abuse the system.) His post here really makes me suspect that might be the case -- it's a "high performance" laptop that he doesn't need and doesn't care enough about to fix it out of his own pocket. There's no proof of who broke it, so taking the far more expensive route past a judge is an expensive gamble.
Yes, yes. Let's waste our time and money in court costs and lawyers fees to get $200 for a laptop screen out of the airline because you were too much of an idiot to either pack the laptop properly (assuming, as the airline states, it wasn't broken before hand) or carry it with you.
And let's not forget, he doesn't want to spend any of his money on it as he "has other laptops" -- read: "I don't need this laptop."
(disclaimer: He never said anything at all about what that laptop actually is. So the age, value, and repair costs are completely unknown.)
Read the fine print. The airline is not responsible for the damage. Do. Not. Check. Laptops. Carry it with you at all times. Common luggage offers little if any protection for a laptop. Have you ever watched how the baggage handlers "handle" luggage?
What? He doesn't have any form of insurance of his own? The cost of a screen is substantially cheaper than the cost of a new laptop. (unless it's an old and/or crappy laptop.)
I've found most "sysadmin" IT types are not good cable makers -- lack of training, lack of desire, lack of experience (how often does making a cable come up?)... As a "network engineer", I know how to make a cable as well as why it's made that way.
There are lots of reasons a random cable may work at 100m but not 1000m. 1000bT uses all 4 pairs at much higher frequency -- the longer the run, the more important that becomes.
That said, fixing a keystone or patch panel is a lot easier than a bad crimp.
Stop fooling yourself; those mass produced cables are not "pre-tested". They aren't tested at all. I've found plenty that wouldn't pass a continuity test, much less a spectrum test. Give the cables are made faster than they can be tested, the best you can expect is "batch testing".
The only reason to buy premade cables -- in bulk -- ... TIME. The only time I'll make a batch of cables is when I have very little else to do. (or don't want to wait for a box to arrive.)