You proceed with the assumption giving the user another choice is better, but that is not always so, and in particular, it's not great to offer the user options that will result in frustrations. See: The Paradox of Choice: Why More is Less -- Barry Schwartz or This Google TechTalks video
In the case of 'Flash' the choice to include it means a crappy experience viewing Flash-enabled web sites in the device, VERSUS being a little upset about not being able to view the site on the mobile device, and having to go to the PC later.
Thus... not having the crappy browsing experience with the mobile device (sluggishnes and crashing) is better, even though it also means there are fewer sites the user can pick to visit.
He's not holding the web at ransom, he's holding iPhone and iPad users at ransom,
because they are the only people this really hurts (or helps).
Except it's Stevie, so he's not making any compromises.
There is some merit to his position, by the way, but it may be at Apple's expense (depending on how much $$$ Adobe wants to license Flash)
It's not a question of how great cool or widespread the Flash technology is in general.... its a question more of cost and how suitable the implementations are available for the iOS devices.
If most Flash apps won't work anyways, there's no point in allowing a broken framework, instead of pushing the next greatest standard.
It's risky, but if Flash is not suitable for mobile platforms it WILL be a thing of the past.
The question I would have is --- why is the article presenting skewed numbers, and including PC and Netbook users?
Netbook users may be more comparable to iPad users; but it's totally ridiculous to pit PC users against iOS users, and
say a technology used on the web for PC users is suitable for mobile browsing
A simple reboot of the system to apply the updated kernel fixes the "backdoor".
What you have in memory until you reboot is a kernel that has already being exploited.
Which the folks at Ksplice probably want to call a backdoor, because they're selling a "rebootless" patch product,
based on the idea you should be able to fix the bug without restarting the kernel.
That's a fine idea, but turns out to be a complete garbage notion, if your Kernel has already been tampered with in memory, so the resident binary doesn't match the source code.
Turns out the "rebootless" patch probably doesn't work so well, if your kernel's in-memory state has already been changed as a byproduct of an exploit.
That is true not only of this exploit, but probably many kernel vulnerability exploits, especially any that involve memory corruption, or installing a code stub to facilitate the exploitation process.
If you have a kernel exploit you invoked, the exploit successfully messed with kernel memory, and want your system back to a pristine boot, you must reboot.
I would not call it a rootkit, unless the "backdoor" were intentionally placed there for the purpose of being a hidden backdoor or enabling covert hacker activity, or (specifically) intended to continue to work either remotely or after you patched, after you rebooted, etc.
Guns have essential purposes. The feeling of necessity is fine, particularly for a hunter, or one who uses a Gun only to ensure their safety and rights.
Shooting at other people's property "for fun" is not part of "gun culture", protected or legal,
it is a stupid, dangerous, illegal prank.
Someone could get hurt, property can be damaged, and nobody has any right to do that.
By all rights, Google should not have to put their cabling underground; the specific "hunters" responsible should be in convicted of a felony, jailed, and never allowed to touch a gun again.
However, the truck is only driving because it is carrying items around.
A certain percentage of its trip is attributable to your item.
Your item uses up a limited resource, physical volume in the vehicle.
And if your item is significantly heavy, for example, you are having a 500 pound lawnmower delivered, or say a really really big rock,
it can have some increase in the gas consumption of the truck.
So yes, a certain amount of gasoline is attributable to carrying your particular item.
That would be one of the following...
The total number units of items you have on the truck, divided by the total number of units the truck was loaded with, multiplied by the total gas the truck consumed from the start of its journey, until the end of its journey when all items were delivered.
Or... the total volume of your item, divided by the total volume of items carried, multiplied by total gas consumed.
The basic idea: by some miracle, if your item was the only item on the truck, then you were responsible for all the gas it consumed.
If there were two items on the truck, your item and some other person's item, of equal size: then the two of you, are equally responsible for
about half the gas consumed by the truck.
Of course: this is on average. If you wanted to be precise, you would have to consider things like optimal routing; it is very possible the second delivery could require the truck to travel extra distance it would not have to travel, otherwise.
For example: if you had a friend from down the road ship you an item, versus your next door neighbor who was having an item shipped from a few thousand miles away.
It is also oversimplistic to assume just one truck -- shipping companies use many trucks, they even have separate trucks for delivery VS trucks to transport items between shipping centers, as this is more efficient.
Not. I hate Access.
I loathe Access.
I'm sometimes forced to use it, usually as a result of stupid decisions made by n00b devs or sadistic PHBs, in the past.
Perhaps, but PostgreSQL had the single most important extension AUTO_INCREMENT as a column type which easily trumped all of MySQL's advantages.
While MySQL just had this clunky 'sequences' concept.
<Co-Pilot> Hey, George... the radar says there's a plane there, think we should pull up?
<Pilot> Don't be silly, Marv, look out there, see out the window, no plane there.
<Co-Pilot> Oh, I see... just a bunch of birds.. they kinda almost look like people. We can take them
<Pilot> I'll aim for the one that almost looks like a stewardess...
... 15 minutes later...
<Reporter> We bring you live to the scene of this terrible accident, it seems a local crop dusting craft.. has collided with "something invisible that noone's figured out what is".
<Reporting> In other news, Invisible Airbus flight 999 disappeared without a trace, we are still searching for the whereabouts of her crew and 50 passengers; more on this at the top of the hour, stay tuned...
Linux 2.2 wasn't released until 1999.
12 years ago, we were using a tool you probably never heard of called ipfwadm, and before that ipfw
Linux's firewalling capabilities have always been miles ahead of Windows' built-in firewall capabilities in terms of being functional, flexible, and easier to get to do what you want for the power user.
Windows, ZA, Comodo used to be ahead in terms of usability for the average user.
Linux firewalling capabilities improved a bit over time, they became more powerful and more user friendly (at least for the Linux admin), more capabilities were introduced in the form of modules.
However, Linux firewalling didn't change much --- it's pretty hard for something that is already nearly perfect to evolve.
On the other hand Windows had and still has a lot of ground to cover in regards to improving the firewall.
It is more cumbersome than ever to add firewall rules or exceptions to the Windows firewall.
No simple text-based language.
No built in rapid CLI-based addition method (have to resort to still a cumbersome GUI to do it).
Try blocking outgoing connections with the XP firewall.
Try upgrading to Windows 7 and using Windows Advanced Firewall instead of a 12-year-old product ?:)
Worrying about blocking outgoing connections with ye' ol' windows XP firewall is kind of like worrying about duplex printing on a 80s/early 90s-era dot matrix printer <G>
Plus, what's to stop you from brute-forcing the unlock procedure? Will the CPU permanently disable itself after a few tries?
No. The dedicated unlock circuit would have a 20 second countdown timer. After powering on the CPU, there would be some brief waiting period you have to endure before the CPU is ready to accept an unlock command. After a failure, you would have to wait 30 seconds before another attempt. Also, after 10 attempts, the security circuit would disable itself until the CPU is powered off for at least 30 seconds.
So the result is you can try approximately 2 unlock attempts per minute on average.
If there are 128 bits, then it will take you approximately 10^33 years to unlock by brute force.
But what would be the chances of that happening? I think that storing millions of unlock codes for years when only a fraction of them will ever be used sounds like it's unneccessarily expensive.
If each unlock code requires storing 128 bytes, then 12 gigabytes is enough to store 100 million unlock codes, and 240 gigabytes is enough to store 2 billion unlock codes.
Enterprise storage is about $0.30 a gigabyte per year, and getting cheaper every year, so you are talking gasp $72 a year to store 2 billion unlock codes. There are costs involved, but storage is not a significant one.
SELinux and Apparmor can't do much if you have an exploit that allows you to execute arbitrary code inside the kernel (which I believe this does). But they'll certainly stop the kind of random buffer overflow exploit that's been the most common avenue of remote attack.
They will stop the simple use of a buffer overflow exploit to do something the program with the vulnerability couldn't do.
That is: a buffer overflow exploit allows running arbitrary code in the context of the program.
SELinux limits what files can be accessed by arbitrary code based on security labels.
However, if there is also a vulnerability in the kernel. SELinux cannot stop a buffer overflow in a program from being used in conjunction with a kernel vulnerability, to run arbitrary code in kernel mode.
Basically: buffer overflow in a program + kernel escalation bug = SELinux or AppArmor fail
You don't necessarily need shell access, just the ability to run a binary as any user.
This could be done, for example, if it is a web server and there is a PHP script with a vulnerability.
If a hacker can run arbitrary PHP code, then they can run code to accept an upload of the binary.
Once the binary is uploaded to a world-writable directory such as/tmp or/var/lib/php/sessions,
the hacker can use the ability to run arbitrary PHP code again to invoke fchmod(), make the binary executable then use the system's dynamic loader and execute the binary, as in
passthru("/lib/ld-linux.so.2/path/to/some/exploit/binary");
The exploit in question actually includes a SELinux bypass. SELinux and AppArmor are not as great as you think; they are understood well enough that hackers can defeat them, and they are deployed on enough systems that hackers write their exploits so these protections are defeated.
A web hosting company might give people the ability to run PHP scripts on the web server.
The user could cross-compile an exploit binary, upload it to the web server, then write a PHP script to cause the exploit binary to run non-interactively as a means of opening a backdoor where further access could be obtained.
I don't doubt someone could physically defeat the control on their own CPU, but it's possible to make physical access required.
I don't think you understand what i'm suggesting they could do.
Each CPU would have its own unique code passphrase chosen at time of manufacture from a true Entropy source; meaning the bits are random, and the only rule relating a code with the CPU serial number is "lookup the entry in the database".
A cryptographically strong HMAC) would be computed from the code and the features the CPU is being shipped with, and the corresponding solder bridges would be burned by the laser, to physically incorporate the CPU's individual code.
To lock a core, a fusible link is inserted between each core's Vcc+, and ground, making the core unable to be powered on unless the physical link is broken by transmitting a high voltage.
The fusible link is controlled by a relay attached to a dedicated security circuit, that will only activate the link, once a code has been input.
The security circuit will only allow 10 attempts, with a maximum of 1 attempt every 10 seconds.
After 10 attempts, it will throw a relay that disconnects itself, and charge a capacitor to maintain that state, until the CPU is power loses power for at least 30 seconds, then 10 more attempts can be made.
I'm guessing you have three partitions on your hard drive... a 20 gigabyte Windows partition,
a 5 gigabyte Linux partition, and a third partition that appears to be random data,
the descriptor in your partition table reads type 0 UNKNOWN, or some random type that other OSes won't treat as valid.
To mount this volume you boot another OS first, or boot the 'unknown' partition from external media.
Slashdot Mirror
You proceed with the assumption giving the user another choice is better, but that is not always so, and in particular, it's not great to offer the user options that will result in frustrations. See: The Paradox of Choice: Why More is Less -- Barry Schwartz or This Google TechTalks video
In the case of 'Flash' the choice to include it means a crappy experience viewing Flash-enabled web sites in the device, VERSUS being a little upset about not being able to view the site on the mobile device, and having to go to the PC later.
Thus... not having the crappy browsing experience with the mobile device (sluggishnes and crashing) is better, even though it also means there are fewer sites the user can pick to visit.
He's not holding the web at ransom, he's holding iPhone and iPad users at ransom, because they are the only people this really hurts (or helps).
Except it's Stevie, so he's not making any compromises.
There is some merit to his position, by the way, but it may be at Apple's expense (depending on how much $$$ Adobe wants to license Flash)
It's not a question of how great cool or widespread the Flash technology is in general.... its a question more of cost and how suitable the implementations are available for the iOS devices.
If most Flash apps won't work anyways, there's no point in allowing a broken framework, instead of pushing the next greatest standard.
It's risky, but if Flash is not suitable for mobile platforms it WILL be a thing of the past.
The question I would have is --- why is the article presenting skewed numbers, and including PC and Netbook users?
Netbook users may be more comparable to iPad users; but it's totally ridiculous to pit PC users against iOS users, and say a technology used on the web for PC users is suitable for mobile browsing
A simple reboot of the system to apply the updated kernel fixes the "backdoor".
What you have in memory until you reboot is a kernel that has already being exploited.
Which the folks at Ksplice probably want to call a backdoor, because they're selling a "rebootless" patch product, based on the idea you should be able to fix the bug without restarting the kernel.
That's a fine idea, but turns out to be a complete garbage notion, if your Kernel has already been tampered with in memory, so the resident binary doesn't match the source code. Turns out the "rebootless" patch probably doesn't work so well, if your kernel's in-memory state has already been changed as a byproduct of an exploit.
That is true not only of this exploit, but probably many kernel vulnerability exploits, especially any that involve memory corruption, or installing a code stub to facilitate the exploitation process.
If you have a kernel exploit you invoked, the exploit successfully messed with kernel memory, and want your system back to a pristine boot, you must reboot.
I would not call it a rootkit, unless the "backdoor" were intentionally placed there for the purpose of being a hidden backdoor or enabling covert hacker activity, or (specifically) intended to continue to work either remotely or after you patched, after you rebooted, etc.
Guns have essential purposes. The feeling of necessity is fine, particularly for a hunter, or one who uses a Gun only to ensure their safety and rights.
Shooting at other people's property "for fun" is not part of "gun culture", protected or legal, it is a stupid, dangerous, illegal prank. Someone could get hurt, property can be damaged, and nobody has any right to do that.
By all rights, Google should not have to put their cabling underground; the specific "hunters" responsible should be in convicted of a felony, jailed, and never allowed to touch a gun again.
It should probably be noted one does not dare install bloatware such as ZoneAlarm on such a box, either.. low-powered hardware is a special case <G>
Windows applications will trigger a "do you want to allow this program through the firewall" prompt, easing setup. I haven't seen that on Linux.
The functionality exists..
TuxGuardian
Linux-firewall.org
auto_commit? What's that? No such thing in ISAM, the model is [was] called atomic operations.. also known as LOCK TABLES :)
Depends on what you need to do... pgAdminIII is pretty useful; many of the 'fancy' tools are commercial.
However, the truck is only driving because it is carrying items around. A certain percentage of its trip is attributable to your item. Your item uses up a limited resource, physical volume in the vehicle.
And if your item is significantly heavy, for example, you are having a 500 pound lawnmower delivered, or say a really really big rock, it can have some increase in the gas consumption of the truck.
So yes, a certain amount of gasoline is attributable to carrying your particular item. That would be one of the following...
The total number units of items you have on the truck, divided by the total number of units the truck was loaded with, multiplied by the total gas the truck consumed from the start of its journey, until the end of its journey when all items were delivered.
Or... the total volume of your item, divided by the total volume of items carried, multiplied by total gas consumed.
The basic idea: by some miracle, if your item was the only item on the truck, then you were responsible for all the gas it consumed.
If there were two items on the truck, your item and some other person's item, of equal size: then the two of you, are equally responsible for about half the gas consumed by the truck.
Of course: this is on average. If you wanted to be precise, you would have to consider things like optimal routing; it is very possible the second delivery could require the truck to travel extra distance it would not have to travel, otherwise.
For example: if you had a friend from down the road ship you an item, versus your next door neighbor who was having an item shipped from a few thousand miles away.
It is also oversimplistic to assume just one truck -- shipping companies use many trucks, they even have separate trucks for delivery VS trucks to transport items between shipping centers, as this is more efficient.
Not. I hate Access.
I loathe Access.
I'm sometimes forced to use it, usually as a result of stupid decisions made by n00b devs or sadistic PHBs, in the past.
I guess they assume all those boxes and Styrofoam peanuts will wind up in the land fill instead of recycled or re-used.
Anyone up for eco-friendly packaging materials for shipments?
Perhaps, but PostgreSQL had the single most important extension AUTO_INCREMENT as a column type which easily trumped all of MySQL's advantages. While MySQL just had this clunky 'sequences' concept.
There is an ODBC driver for PostgreSQL. You can probably access a PG database using MS Access just fine...
<Co-Pilot> Hey, George... the radar says there's a plane there, think we should pull up?
<Pilot> Don't be silly, Marv, look out there, see out the window, no plane there.
<Co-Pilot> Oh, I see... just a bunch of birds.. they kinda almost look like people. We can take them
<Pilot> I'll aim for the one that almost looks like a stewardess...
<Reporter> We bring you live to the scene of this terrible accident, it seems a local crop dusting craft.. has collided with "something invisible that noone's figured out what is".
<Reporting> In other news, Invisible Airbus flight 999 disappeared without a trace, we are still searching for the whereabouts of her crew and 50 passengers; more on this at the top of the hour, stay tuned...
Not the only problem... let's have totally transparent cars on the road, transparent skin, engine, body, everything.
There would be fewer crashes that way, right?
ugh.. my comment two down is meant to be the reply to this.
12 years ago, it was not ipchains, it was something even older :)
Linux 2.2 wasn't released until 1999. 12 years ago, we were using a tool you probably never heard of called ipfwadm, and before that ipfw
Linux's firewalling capabilities have always been miles ahead of Windows' built-in firewall capabilities in terms of being functional, flexible, and easier to get to do what you want for the power user.
Windows, ZA, Comodo used to be ahead in terms of usability for the average user.
Linux firewalling capabilities improved a bit over time, they became more powerful and more user friendly (at least for the Linux admin), more capabilities were introduced in the form of modules.
However, Linux firewalling didn't change much --- it's pretty hard for something that is already nearly perfect to evolve.
On the other hand Windows had and still has a lot of ground to cover in regards to improving the firewall.
It is more cumbersome than ever to add firewall rules or exceptions to the Windows firewall. No simple text-based language. No built in rapid CLI-based addition method (have to resort to still a cumbersome GUI to do it).
Try blocking outgoing connections with the XP firewall.
Try upgrading to Windows 7 and using Windows Advanced Firewall instead of a 12-year-old product ? :)
Worrying about blocking outgoing connections with ye' ol' windows XP firewall is kind of like worrying about duplex printing on a 80s/early 90s-era dot matrix printer <G>
Plus, what's to stop you from brute-forcing the unlock procedure? Will the CPU permanently disable itself after a few tries?
No. The dedicated unlock circuit would have a 20 second countdown timer. After powering on the CPU, there would be some brief waiting period you have to endure before the CPU is ready to accept an unlock command. After a failure, you would have to wait 30 seconds before another attempt. Also, after 10 attempts, the security circuit would disable itself until the CPU is powered off for at least 30 seconds.
So the result is you can try approximately 2 unlock attempts per minute on average. If there are 128 bits, then it will take you approximately 10^33 years to unlock by brute force.
But what would be the chances of that happening? I think that storing millions of unlock codes for years when only a fraction of them will ever be used sounds like it's unneccessarily expensive.
If each unlock code requires storing 128 bytes, then 12 gigabytes is enough to store 100 million unlock codes, and 240 gigabytes is enough to store 2 billion unlock codes.
Enterprise storage is about $0.30 a gigabyte per year, and getting cheaper every year, so you are talking gasp $72 a year to store 2 billion unlock codes. There are costs involved, but storage is not a significant one.
SELinux and Apparmor can't do much if you have an exploit that allows you to execute arbitrary code inside the kernel (which I believe this does). But they'll certainly stop the kind of random buffer overflow exploit that's been the most common avenue of remote attack.
They will stop the simple use of a buffer overflow exploit to do something the program with the vulnerability couldn't do.
That is: a buffer overflow exploit allows running arbitrary code in the context of the program. SELinux limits what files can be accessed by arbitrary code based on security labels.
However, if there is also a vulnerability in the kernel. SELinux cannot stop a buffer overflow in a program from being used in conjunction with a kernel vulnerability, to run arbitrary code in kernel mode.
Basically: buffer overflow in a program + kernel escalation bug = SELinux or AppArmor fail
You don't necessarily need shell access, just the ability to run a binary as any user.
This could be done, for example, if it is a web server and there is a PHP script with a vulnerability. If a hacker can run arbitrary PHP code, then they can run code to accept an upload of the binary.
Once the binary is uploaded to a world-writable directory such as /tmp or /var/lib/php/sessions,
the hacker can use the ability to run arbitrary PHP code again to invoke fchmod(), make the binary executable then use the system's dynamic loader and execute the binary, as in
passthru("/lib/ld-linux.so.2 /path/to/some/exploit/binary");
The exploit in question actually includes a SELinux bypass. SELinux and AppArmor are not as great as you think; they are understood well enough that hackers can defeat them, and they are deployed on enough systems that hackers write their exploits so these protections are defeated.
A web hosting company might give people the ability to run PHP scripts on the web server. The user could cross-compile an exploit binary, upload it to the web server, then write a PHP script to cause the exploit binary to run non-interactively as a means of opening a backdoor where further access could be obtained.
I don't doubt someone could physically defeat the control on their own CPU, but it's possible to make physical access required. I don't think you understand what i'm suggesting they could do.
Each CPU would have its own unique code passphrase chosen at time of manufacture from a true Entropy source; meaning the bits are random, and the only rule relating a code with the CPU serial number is "lookup the entry in the database".
A cryptographically strong HMAC) would be computed from the code and the features the CPU is being shipped with, and the corresponding solder bridges would be burned by the laser, to physically incorporate the CPU's individual code.
To lock a core, a fusible link is inserted between each core's Vcc+, and ground, making the core unable to be powered on unless the physical link is broken by transmitting a high voltage.
The fusible link is controlled by a relay attached to a dedicated security circuit, that will only activate the link, once a code has been input.
The security circuit will only allow 10 attempts, with a maximum of 1 attempt every 10 seconds. After 10 attempts, it will throw a relay that disconnects itself, and charge a capacitor to maintain that state, until the CPU is power loses power for at least 30 seconds, then 10 more attempts can be made.
I'm guessing you have three partitions on your hard drive... a 20 gigabyte Windows partition, a 5 gigabyte Linux partition, and a third partition that appears to be random data, the descriptor in your partition table reads type 0 UNKNOWN, or some random type that other OSes won't treat as valid.
To mount this volume you boot another OS first, or boot the 'unknown' partition from external media.