Comment Grain of salt.... (Score 1) 65
I take such news with a grain of salt. In my experience/estimates, about 80% of security experts report "not possible to reproduce/impossible to exploit" for REAL exploitable bugs.
I take such news with a grain of salt. In my experience/estimates, about 80% of security experts report "not possible to reproduce/impossible to exploit" for REAL exploitable bugs.
I'm guessing that of the hundreds of thousands of people who get that "mass mailing", some are reporting the mails as SPAM to the authorities. Even if there is an "unsubscribe link" somewhere.
Those that do this, might have subscribed in the past and now no longer use Microsoft software. Or maybe Microsoft at one point decided to add a class-of-users to the list automatically (which I think they shouldn't have done if they did).
In any case, with so many users, the chances of being reported as spammers are 100%. So I understand the pressure to stop.
Here in holland and across europe the same is being done. The thing is, technically, many homes are hooked up with a line physically capable of say 20mpbs, but with only a 10mbps subscription. The extra bandwidth can be alotted to "guest users".
Similarly, even if someone has a 20(or more) mbps subscription on a 20mbps line, he/she won't be using all of it all of the time. So you can again use part of the bandwidth for guests. In this case it would be fair to give the original subscriber priority to use whatever he/she wants, and put the guests at a lower priority.
Oh, security wise they also separate the original subscriber from the guests.
I have the impression they do this "sensibly": the subscribers don't really have a valid reason to be upset about it.
And the thing is: If you're a subscriber, suddenly there are hundreds or thousands of places where you won't be using your 3G datalink but a wifi hotspot. Faster, cheaper!
Getting into "admin" mode is a big deal. Even if you don't see a direct way of making money off that, someone else might. (see ingenium's post).
And even then, it should be "confidential information" how much money is in there. If the crooks get to check on the amount that's in there over a period, they can decide to crack it open at "just" the right time. Should improve their "profits" by a factor of two on average.
If you're right and absolutely the only thing they can do is to dispense bills into the "not-dispensed" basket, there is a "denial-of-service" attack: Dispense all bills into the wastebasket just after the machine has been filled. Now the machine will be empty until the next refill. VERY annoying for the people who out-of-habit only go to one ATM.
You have this creditcard. It works in the mall, it works at the cinema. You go somewhere where you know your brother/friend/whatever also has a creditcard that also works in the obvious places. Do you remember to call the credit card company?
What if the bad guys manage to find your account details at a badly protected webshop? They call the creditcard company saying you'll e doing a few purchases across the country (or abroad). Try it once or twice to see what the creditcard company asks to verify it's you, and most likely the crooks will be able to prepare that information.
This doesn't fix the problem. It makes the chances of exploitation a bit smaller, on a "per-try" basis.
Back in the old days, some daemons or setuid programs would do insecure things with
target = "/tmp/somefile";
while (1) {
unlink (target);
link ("/etc/passwd", target);
unlink (target);
link ("/tmp/myfile", target);
}
The daemon would check access permissions of the "target", hopefully after the last line in the loop, then open and write the target, hopefully after the second line inside the loop. Leave this running, trigger the target app, and you get the target app to write somewhere where it shouldn't (in this case
The same applies to this stack/compiler randomization tricks: The hacker first tries at a slow pace, but instead of hacking your system, fails to get in because he's crashing your service deamon. You notice your service going down every day or so. Buggy software. Stupid randomization! No time to fix, and you make the daemon restart automatically. And bingo! Now the hacker can try thousands of times!
In cryptography, care has been taken that you can't figure out one of the "bits" of the key by a simple search. So that the exponential search (find the key among 2^256 possible keys) does not become "256 times: find bit n". To guarantee that no "bit leaking" will happen in a buggy program is very, very difficult: The designers of the program don't know where the bug is, the compiler doesn't know where the bug is, but the attacker does!
So... if this goes mainstream, the hackers will find a way to extract little bits of knowledge of the randomization, determine what the actual randomization was, and then attack the service as usual.
Of course, there will be cases where say: the time for the attack is increased beyond the attack-detection-time. So instead of the attack being succesful, the attack might be detected and averted.
Anyway, I much rather have something that actually WORKS instead of "has a chance of working". But maybe that's just me.
As this is from a western company (HP), I expect such technical claims to be reasonably reliable. They claim 1024x768 resolution, which is 100% correct. For something less easy to measure (for me), if they claim 2000 ANSI-lumen, I expect at least say 1800, with the "excuse" something like: we put it on the "boost" setting for that measurement (and then decided not to put it in the final product because it reduces lamp-life a lot).
I decided 15 years ago when I bought my DLP projector that I wouldn't settle for less than 2000 Lumen. Back then this was an expensive "restriction". But 75????
Daniel phillips, where have I heard that name before? It was in the last few days....
To be taken serously, the home page needs to mention something more recent than 2008 in the "on the web" section. And the "we're active, see the git log" link needs to point somewhere other than a 404....
Haha. I worked on a project where the machine doesn't const a lowly $50K. The machine costs on the order of $2M. The machine has processed (I just looked it up) about $40B worth of product... And it's still running software from around '2000. (installed in '97, upgraded in '00)
I wrote software that is now cloned to 5 machines. The machine runs a terribly old OS, no longer supported. But the rest of the machine cost about $2M each....replacing them or part is not an option! So: don't connect it to the internet. These machines have processed countless billions worth of product. The product is worth more than whatever can be found on the machine, so yes the operators will be able to use a privilege escalation bug to gain root access.
Anyway, they run Linux 2.4 on Suse 7.2....
Same here.
> Yes.... but I belive that's more about HONORING What you advertise.
> If the printed price they stuck on the goods says "$300" on a $3000 on
> a brand new Macbook pro; they better honor it.
In The Netherlands, the law states that they have to honour the advertized price as long as it can be reasonably assumed not to be an error. With mega-discounts and super-cheap deals for various products the "spot the error" can become difficult. On the other hand, the $300 on the $3000 macbook would be considered an "obvious error".
The $80 for a $800 flight however cannot! The cheap airlines have been selling fights for that kind of rates for ages, so even when an airline that normally doens't do this proposes such a deal, that should be considered "entirely plausible" by the consumer.
The "bends" in the curve they plot are too abrupt. There must be something else going on.
Looking at the original article, they had only about 3500 drives around 2009. That's 4 years ago. So their "4 year" survival rate is not based on the 25000 drives they have now, but only on the 3500 that they had in 2009. With the sharp bends in the curves around 1.5 years and 3 years, I think they significantly changed their buying policy around those moments. Or the manufacturers started shipping them different drives.
How else can the drive "know" that it's been on for 1.5 years? The annual failure rate drops by a factor of four inside a month.
The explanation of the bathtub curve eplains it a bit, the random failures is apparently about 1.4% per year. The initial failure is about 5.1-1.4= 3.7 per year. But instead of the initial failures "tapering off" to "small" values around 1.5 years, they stay constant for 1.5 years, and then suddenly drop to zero. To me this points to something like: "they bought a big batch of drives about 1.5 years ago that has such a high random-failure-rate to pull the average first-1.5-year average up to 5.1%/year".
Do the same analysis 3 months from now, and the "1.5 year bend" moves over to 1.75 years. That's my hypothesis based on the data they publish. Having the underlying data and some time to spare, the current data may debunk or prove my hypothesis already. (e.g. if you run the analysis on the data that is now older than 3 months will, if my hypothesis is correct, show the bend around 1.25 years. If that happens, it makes my hypothesis very likely.....)
Air pollution is really making us pay through the nose.
