They found a statistical relationship between the results from "normal" people and "people with cancer". This means that it MIGHT be possible to develop this into a test.
But this "result" (a statistical difference) might be that they got an average score of 98 +/- 10 for the healty people and 102 +/- 10 for the people-with-cancer. So someone who scores 100, healty or has cancer? 105? Can still go both ways.
The number of passengers has been adjusted from 280 to 283. There were 15 crew on board.
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.
Anyone can make an omelet with eggs. The trick is to make one with none.
