One of C's great advantages is not only that it is simple and very fast, it is also very close to the hardware -- when you make local variables, structures, assignments, etc... you have a good idea what the compiler needs to do. Likewise control structures, statements and so on.
That’s exactly the point... it’s too close to the hardware. Yes, it gives you really fine-grained control over what happens, and you can tweak it to make it as fast as possible. With the speed of today’s computers, though, you shouldn’t (usually) need that amount of optimization. Plus, the compiler should be robust enough to optimize the program nearly as well as you could anyway.
You don’t want to tell the computer every nitty-gritty detail. The computer is fast enough and powerful enough to do what you want it to do without you needing to exercise that level of control over how it actually does it. You just want to call a function that does what you want without worrying about the underlying hardware or algorithm that does it.
As programs get more and more complex, more and more abstraction is needed between the programmer and the hardware. This is not surprising. Someday, instead of saying “that’s like coding an entire application in assembly”, we might be saying “that’s like coding an entire application in C++”.
You don't think the same current at a higher voltage (more power) will cause it to heat up faster?
Electricity does not work that way.
Assuming the resistance of the wire does not change greatly (which it should not, at least until right before it blows), more voltage = more current = more heat. You can’t just have “the same current at a higher voltage”. Ohm’s Law doesn’t work that way.
The flaw that isn't going to be fixed "in the near future" is the "if a shortcut's icon is shown in Windows Explorer, then automatic execution of malicious code may occur"
I’m still not sure where that idea comes from. Microsoft admitted a flaw in the icon display code for shortcuts (“When attempting to load the icon of a shortcut, the Windows Shell does not correctly validate specific parameters of the shortcut.”), so presumably they will be patching it shortly.
Well, looks like I might have misunderstood the advisory. Further down in the details:
When attempting to load the icon of a shortcut, the Windows Shell does not correctly validate specific parameters of the shortcut.... An attacker could present a removable drive to the user with a malicious shortcut file, and an associated malicious binary. When the user opens this drive in Windows Explorer, or any other application that parses the icon of the shortcut, the malicious binary will execute code of the attacker’s choice on the victim system.
From this, it appears that the part about clicking was rather misleading in that you do not have to click the icon for the exploit to execute.
However, it also requires a secondary malicious binary in addition to the malicious shortcut, and it seems to me that AV software could easily be updated to detect and clean this sort of malformed file. In the meantime, I would suggest disabling Autoplay and using particular caution when using removable storage devices that have been outside your control.
Note that it does state that the exploit can only escalate its privileges to the same privileges as the local user account, so this is yet another reason that you should not be logged in as an Administrator on your own PC.
The vulnerability exists because Windows incorrectly parses shortcuts in such a way that malicious code may be executed when the user clicks the displayed icon of a specially crafted shortcut.
Sounds like a vulnerability in the way the Details panel in Explorer is updated when the user highlights a maliciously malformed icon. However the MS page did indicate that the user has to actually click on the icon, so it appears that simply autoplaying the drive would not be enough to infect you (unlike some of the PDF/JPEG - or was it PNG - exploits that I seem to remember which infected your computer by an exploit of the code that generated the Explorer thumbnail). That said, merely highlighting an icon absolutely should not execute any untrusted code.
In the meantime, prudent action would be to keep your OS and AV updated, take care of USB removable storage devices, and not click on any shortcut files on external devices unless you’re certain of their source and trustworthiness. It might also not be a bad idea to modify your Windows registry to show the.lnk extension on shortcut files. Remove the HKEY_LOCAL_MACHINE\SOFTWARE\Classes\lnkfile\NeverShowExt key:
Microsoft states that they are still reviewing the vulnerability and I assume they will patch it as soon as they can. The claim that they have “no plans to patch” appears to be not a bit true.
According to TFA, he had been known to come into her room for no apparent reason while she was sleeping. She said she had awoken to him standing over her bed in the past.
The warning signs were likely there, but nobody was paying enough attention.
Attempted rape or even rape itself is not a good reason to murder someone.
Murder is the unjustified killing of another human being. Killing a rapist or attempted rapist in self-defense is entirely justified and thus it is, by definition, not murder. Your statement was correct, although probably not in the sense that you meant it.
Re: last paragraph. Your problem isn’t the car keeping going, it’s the stuck accelerator. Making the car stop going MIGHT be profitable in the short-term (if you sense an impending crash) but if you have plenty of space, making the car stop going while the engine is still racing is a stupid alternative where better ones exist (stopping the engine).
Yes, that was basically my initial thought when I said make it a “random” delay. If you contaminate the randomness by adding the length of your verification subroutine, it’s no longer random. A good way to describe it, as you stated, is to pad out the time (eliminate the variance of your verification subroutine) and then add a random amount on top (easy enough to do at this point, and making attackers scratch their head a little).
No, you retard, if the fixed delay was identical plus a random delay that wasn’t identical, you wouldn’t even need billions of attempts. You don’t care WHAT the fixed delay is, you only care whether it’s more or less than the fixed delay of another.
I.e.
is A > B?
Is A + random > B + random?
Average it out and the “random” goes to a constant:
We are NOT fucking talking about a SINGLE measurement of time.
We are talking about hundreds - possibly thousands - of "value", plus your random number. Guess what. Your stupid random number averages out to its median over about 1000 attempts. Meanwhile the CONSTANT value remains CONSTANT and as only the RELATIVE position of the values was important, we can compare it to OTHER attempts and determine which was faster REGARDLESS of your stupid random number.
You average it out.
No, I do not expect you to understand that any more than you understood the more helpful (and less insulting) version. You are an idiot.
Yeah, that was basically my thought, but instead of a constant X you use a random number that’s guaranteed to be longer than all expected processing times.
In my haste to get first post I couldn’t think of any way to express that quickly, but yeah.
Taking a constant amount of time is likely just as hard as taking a random amount of time as I described. The only difference is that you are padding to a fixed number instead of a random one.
Not just a random delay, per se. You are absolutely right.
To avoid contaminating the random delay with a fixed bias (which can easily be determined by running the same query enough times), the timer has to start at the very beginning, delay for longer than the password-checking algorithm will ever take, then return the result after the preset random length of time has elapsed.
I.e. wrong:
Verify + Random = Result
Result depends on Verify. You just have to average out Random by repeating it enough times. You’ve contaminated your randomness by biasing it with a fixed number that depended on the input.
but correct, and more easily expressed in a multi-threaded sense,
Thread 0: Verify
Thread 1:.....Random..... + Copy result from finished Verify = Result
Result does not depend on Verify. Random just has to be long enough to ensure that Verify will always complete.
My idea of a “random delay” isn’t quite a random delay but rather more of a “pad to a random length”. I.e. if the operation takes between 50-600us, pick a random length between 1000-2000us, start the timer at the beginning, call the routine, and when all is said and done just go to sleep until the total elapsed time reaches the random value you initially picked.
You are correct in that simply delaying for a random amount of time merely blurs the window for detection.
I.e. if you simply added 0-1000us and the routine took 50us, it now takes 50-1050us. However, if you repeat the same input a few hundred times, the average time will converge to about 550us, whereas a call that took 500us will converge to 1000us. You only made the attack take longer.
If you pad to a random value between 1000-2000us, no matter how many times the same input is repeated it will just converge to 1500us, giving the attacker no knowledge of the time taken to check the password.
The easiest way to do this would probably be to use two separate threads: one thread delays a random amount of time then return the result, the other thread checks the password and stores the result in a shared memory location. Just ensure that the password-checking thread will always finish before the delay-then-return thread does. This way the amount of time you actually delay will not depend at all on the amount of time taken to check the password. However you would need a fairly good understanding of the architecture so as to make sure that the two threads would not be able to interfere with each other in a way that would contaminate the randomness of the delay length.
Explaining all of that took a while, though, and I needed to hurry to get my first post.;)
Slashdot Mirror
One of C's great advantages is not only that it is simple and very fast, it is also very close to the hardware -- when you make local variables, structures, assignments, etc... you have a good idea what the compiler needs to do. Likewise control structures, statements and so on.
That’s exactly the point... it’s too close to the hardware. Yes, it gives you really fine-grained control over what happens, and you can tweak it to make it as fast as possible. With the speed of today’s computers, though, you shouldn’t (usually) need that amount of optimization. Plus, the compiler should be robust enough to optimize the program nearly as well as you could anyway.
You don’t want to tell the computer every nitty-gritty detail. The computer is fast enough and powerful enough to do what you want it to do without you needing to exercise that level of control over how it actually does it. You just want to call a function that does what you want without worrying about the underlying hardware or algorithm that does it.
As programs get more and more complex, more and more abstraction is needed between the programmer and the hardware. This is not surprising. Someday, instead of saying “that’s like coding an entire application in assembly”, we might be saying “that’s like coding an entire application in C++”.
Better pictures here:
http://androidos.in/2010/07/35-android-tablet-is-here-in-india-price-can-go-down-to-10/
You don't think the same current at a higher voltage (more power) will cause it to heat up faster?
Electricity does not work that way.
Assuming the resistance of the wire does not change greatly (which it should not, at least until right before it blows), more voltage = more current = more heat. You can’t just have “the same current at a higher voltage”. Ohm’s Law doesn’t work that way.
My DVD player disables certain functions while it is playing advertisements.
Sigh. I’m so tired of the users-vs-product debate. It’s a ring arrangement. You can’t call any particular one a “product”.
Users need services provided by Facebook who needs revenue which they get from their advertisers who need the users to view their ads.
Is that really so complicated?
De-fragmentation is a necessary evil but it should be done silently and automatically using the computer’s idle background resources.
The flaw that isn't going to be fixed "in the near future" is the "if a shortcut's icon is shown in Windows Explorer, then automatic execution of malicious code may occur"
I’m still not sure where that idea comes from. Microsoft admitted a flaw in the icon display code for shortcuts (“When attempting to load the icon of a shortcut, the Windows Shell does not correctly validate specific parameters of the shortcut.”), so presumably they will be patching it shortly.
Well, looks like I might have misunderstood the advisory. Further down in the details:
When attempting to load the icon of a shortcut, the Windows Shell does not correctly validate specific parameters of the shortcut. ... An attacker could present a removable drive to the user with a malicious shortcut file, and an associated malicious binary. When the user opens this drive in Windows Explorer, or any other application that parses the icon of the shortcut, the malicious binary will execute code of the attacker’s choice on the victim system.
From this, it appears that the part about clicking was rather misleading in that you do not have to click the icon for the exploit to execute.
However, it also requires a secondary malicious binary in addition to the malicious shortcut, and it seems to me that AV software could easily be updated to detect and clean this sort of malformed file. In the meantime, I would suggest disabling Autoplay and using particular caution when using removable storage devices that have been outside your control.
Note that it does state that the exploit can only escalate its privileges to the same privileges as the local user account, so this is yet another reason that you should not be logged in as an Administrator on your own PC.
The MS Security Advisory (2286198) states,
The vulnerability exists because Windows incorrectly parses shortcuts in such a way that malicious code may be executed when the user clicks the displayed icon of a specially crafted shortcut.
Sounds like a vulnerability in the way the Details panel in Explorer is updated when the user highlights a maliciously malformed icon. However the MS page did indicate that the user has to actually click on the icon, so it appears that simply autoplaying the drive would not be enough to infect you (unlike some of the PDF/JPEG - or was it PNG - exploits that I seem to remember which infected your computer by an exploit of the code that generated the Explorer thumbnail). That said, merely highlighting an icon absolutely should not execute any untrusted code.
In the meantime, prudent action would be to keep your OS and AV updated, take care of USB removable storage devices, and not click on any shortcut files on external devices unless you’re certain of their source and trustworthiness. It might also not be a bad idea to modify your Windows registry to show the .lnk extension on shortcut files. Remove the HKEY_LOCAL_MACHINE\SOFTWARE\Classes\lnkfile\NeverShowExt key:
Microsoft states that they are still reviewing the vulnerability and I assume they will patch it as soon as they can. The claim that they have “no plans to patch” appears to be not a bit true.
According to TFA, he had been known to come into her room for no apparent reason while she was sleeping. She said she had awoken to him standing over her bed in the past.
The warning signs were likely there, but nobody was paying enough attention.
Attempted rape or even rape itself is not a good reason to murder someone.
Murder is the unjustified killing of another human being. Killing a rapist or attempted rapist in self-defense is entirely justified and thus it is, by definition, not murder. Your statement was correct, although probably not in the sense that you meant it.
Re: last paragraph. Your problem isn’t the car keeping going, it’s the stuck accelerator. Making the car stop going MIGHT be profitable in the short-term (if you sense an impending crash) but if you have plenty of space, making the car stop going while the engine is still racing is a stupid alternative where better ones exist (stopping the engine).
Yes, that was basically my initial thought when I said make it a “random” delay. If you contaminate the randomness by adding the length of your verification subroutine, it’s no longer random. A good way to describe it, as you stated, is to pad out the time (eliminate the variance of your verification subroutine) and then add a random amount on top (easy enough to do at this point, and making attackers scratch their head a little).
No, you retard, if the fixed delay was identical plus a random delay that wasn’t identical, you wouldn’t even need billions of attempts. You don’t care WHAT the fixed delay is, you only care whether it’s more or less than the fixed delay of another.
I.e.
is A > B?
Is A + random > B + random?
Average it out and the “random” goes to a constant:
Is A + R > B + R?
Yes or no. It’s that simple.
You are an idiot.
You are talking about speed, which is irrelevant because we are already purposefully slowing it down.
I am talking about programming complexity.
GODDAMN. You really ARE that stupid.
We are NOT fucking talking about a SINGLE measurement of time.
We are talking about hundreds - possibly thousands - of "value", plus your random number. Guess what. Your stupid random number averages out to its median over about 1000 attempts. Meanwhile the CONSTANT value remains CONSTANT and as only the RELATIVE position of the values was important, we can compare it to OTHER attempts and determine which was faster REGARDLESS of your stupid random number.
You average it out.
No, I do not expect you to understand that any more than you understood the more helpful (and less insulting) version. You are an idiot.
some glyphs are accessible but only via entity names
Nope, they fixed that too.
Yeah, that was basically my thought, but instead of a constant X you use a random number that’s guaranteed to be longer than all expected processing times.
In my haste to get first post I couldn’t think of any way to express that quickly, but yeah.
Taking a constant amount of time is likely just as hard as taking a random amount of time as I described. The only difference is that you are padding to a fixed number instead of a random one.
Headlines and subjects still seem to act screwy sometimes, and I haven’t found the rhyme or reason to that yet.
Not just a random delay, per se. You are absolutely right.
To avoid contaminating the random delay with a fixed bias (which can easily be determined by running the same query enough times), the timer has to start at the very beginning, delay for longer than the password-checking algorithm will ever take, then return the result after the preset random length of time has elapsed.
I.e. wrong:
Verify + Random = Result
Result depends on Verify. You just have to average out Random by repeating it enough times. You’ve contaminated your randomness by biasing it with a fixed number that depended on the input.
but correct, and more easily expressed in a multi-threaded sense,
Thread 0: Verify .....Random..... + Copy result from finished Verify = Result
Thread 1:
Result does not depend on Verify. Random just has to be long enough to ensure that Verify will always complete.
My idea of a “random delay” isn’t quite a random delay but rather more of a “pad to a random length”. I.e. if the operation takes between 50-600us, pick a random length between 1000-2000us, start the timer at the beginning, call the routine, and when all is said and done just go to sleep until the total elapsed time reaches the random value you initially picked.
You are correct in that simply delaying for a random amount of time merely blurs the window for detection.
I.e. if you simply added 0-1000us and the routine took 50us, it now takes 50-1050us. However, if you repeat the same input a few hundred times, the average time will converge to about 550us, whereas a call that took 500us will converge to 1000us. You only made the attack take longer.
If you pad to a random value between 1000-2000us, no matter how many times the same input is repeated it will just converge to 1500us, giving the attacker no knowledge of the time taken to check the password.
The easiest way to do this would probably be to use two separate threads: one thread delays a random amount of time then return the result, the other thread checks the password and stores the result in a shared memory location. Just ensure that the password-checking thread will always finish before the delay-then-return thread does. This way the amount of time you actually delay will not depend at all on the amount of time taken to check the password. However you would need a fairly good understanding of the architecture so as to make sure that the two threads would not be able to interfere with each other in a way that would contaminate the randomness of the delay length.
Explaining all of that took a while, though, and I needed to hurry to get my first post. ;)
€
Nope, copy-and-paste works just fine for £ and €. Copy-and-paste works fine for all of the whitelisted characters.
£ ¥ ¦ © ® ± ¼ ½ ¾ – — ‘ ’ “ ” €
À Á Â Ã Ä Å Æ Ç È É Ê Ë Ì Í Î Ï
Ð Ñ Ò Ó Ô Õ Ö × Ø Ù Ú Û Ü Ý ß
à á â ã ä å æ ç è é ê ë ì í î ï
ð ñ ò ó ô õ ö ÷ ø ù ú û ü ý ÿ
n/t