What happens when the SWF is in a valid image container and also contains an image in it?
Then the thumbnail can be generated just fine, but flash can happily be able to execute the SWF also in the container...
Some of the image and video container file formats are generic enough that both flash content and media can be embedded in the same container file.
The only way a website can hope to validate is to be able to parse every single container format that current versions of the Flash plugin are able to look inside and pull flash from..
If you are a millionaire with a couple million. I don't think you'll want to buy a $1 million toy. Also, imagine the sales/use tax on that you'll be paying to your state, probably another 100 or 200k, unless you're in Alaska, Delaware, Montana, New Hampshire, or Oregon.
These kind of sentiments have been advanced by closed source vendors for ages - just listen to Apple and AT&T about how giving me access to iPhone is too dangerous for my own good.
This is a bit different, don't you think?
A pacemaker's not an iPhone. Your heart's not a replacable commodity, it's not an entertainment, communications, or general computing device.
You break your iPhone: you're out $500, or you undo your change. You break your pacemaker, and your dead. There's no chance to "test" your change.
either manufacturer goes out of business or the software doesn't work for my specific need
A pacemaker's not a device you should be wanting to customize.. It has exactly one function, and it should just work.
If the building is burning and fire department is nowhere in sight?
Any analogy can be extended to absurdity.
There is no equivalent with pacemakers that can be handled in the same way.
If a pacemaker seems to be malfunctioning, tampering with it yourself, is certainly the wrong thing to do, plus it would take too long, and you'd be dead already.
Actually.. the thing is they're willing to do a half-assed job at keeping it working, as long as it's profitable.
In this case, fixing security requires "breaking" it for customers with legitimate content, we can see they don't want to do that. They only want to do things that will sell get them more sales and make sure Flash stays dominant over threats such as Silverlight.
Then they do a quarter-assed job at keeping it up-to-date
It can't eat the hosting webserver, but it's running on the clients' computers if they have flash installed.... it means the app could do things like submit forms, e.g. pretend to be that person, cause that person to also upload a flash file as their avatar, modified so it "appears" to be the original image of them... then post in a thread as them.
There is no vulnerability if the clients don't have flash installed.
It's a client-side vulnerability.
Given flash's popularity, webmasters should understand the risk and block uploads of.SWFs and application/x-flash
However, expecting webmasters to scan.jpeg uploads of declared type image/jpeg or declared application/octet-stream uploads to determine if flash might execute them, when they are intended to be simple downloads or image displays is way over the line...
Especially if an attacker can construct an image file that is a valid image, but flash will pick up and execute......
Since almost all web-apps check content by the Content-Type and file extension; it's either not broken or is in very good company (you're essentially saying everything is broken, including Gmail's ability to attach image files such as.jpegs of declared type Image/Jpeg which are actually SWFs)...
By far it is flash that is broken.
The flash plugin shouldn't execute on image/jpeg content types.
They are simply ignoring web standards and executing code if the magic number matches.
This is clearly a bug in flash.
I don't think people need to be protected excessively by the government.
However, I don't think manufacturers should have to help them.
I for one welcome our new medical device DRM overlords.
Manufacturers have an interest in minimizing their liability, and maintaining their good name: that means no end-user modifications.
They also have an interest in not looking bad when one of their device malfunctions and kills someone due to tuning done by some doctor.
They also have an interest in keeping competitors from getting easy access to their firmware in order to leverage knowledge from it in making their own devices.
If you want to design your own pacemaker and take all the responsibility yourself if it is unreliable due to your tweaks, fine, as long as you can find a doctor to go along with it.
If not, then leave pacemaker design to the professionals..
Just like you don't perform your own brain surgery on yourself.
I'm all for hardware hacking, repurposing Xboxes as computers, etc. In general DRM sucks.
But a pacemaker's not a toy to play around with.
It's not a thing to hack. At least, one that's in use or that might ever be used isn't
That's because a 'button' is a visual cue to the user by the browser that this element will perform a POST action if pressed. it's a way of ensuring the user knows they aren't just following a passive link.
If you want to use a non-standard element such as a link for that, you should script it.
It happens to be really easy to script POST submission.
So you have the option of using scripting/CSS to style your links, or you can use the standard widgets users are familiar with:
Links for idempotent information requests. Submit or Button elements for requesting actions.
Is it too much to ask that such a critical device have two firmwares, the 'user installed firmware', a 'backup firmware', and a monitor ROM?
If the monitor ROM detects the device going out of certain parameters, or detects an exception in the user firmware, it switches to an emergency firmware ROM with assured "safe settings", and starts emitting a radio signal to be picked up by authorities, and possibly alarm tone to warn the user..
No, you should have the right to go to a medical practitioner and have approved safe updates to the device applied in a safe manner.
User firmware upgrades on life critical devices are a bad idea.
What happens if your computer crashes while trying to update the firmware, or the connection times out? What happens if you got a bad image, or the wrong firmware version for the specific chip revision of your device?
Is the pacemaker fully working during such an upgrade?
Sorry... the risk that you brick your pacemaker is too great; I don't think anyone has a proper right to take such risks.
Just like people will stop you if you plan to jump from the roof of a 3-story building to try and hit a trampoline on the ground floor.
Device manufacturers have every right to implement anti-tampering safety measures on a device like this one.
If the firmware's going to be upgraded manufacturer approval is a must.
Otherwise... who's going to be liable when the device fails? You won't be.
The freedom to improve the program, and release your improvements (and modified versions in general) to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.
...
In order for the freedoms to make changes, and to publish improved versions, to be meaningful, you must have access to the source code of the program. Therefore, accessibility of source code is a necessary condition for free software.
Multiple incompatible languages winding up with the same name is par for the course in the compiler industry.
You have any idea how many different compiler vendors call completely different languages BASIC ?
How many different incompatible implementations of C there were (before ISO standardization)?
If something's not widely commercialized with name rights locked up tight, or ANSI/ISO standardized, then you are asking for incompatible competing implementations, or even totally different languages, all going by the same name, unless you secure rights to the name.
Also, Go! is such a short and generic title for a programming language, that noone should get to use it unless they can make a famous name out of it.
In fact, other languages use GO as a statement or keyword in the language, from before 2003. E.g. T-SQL. And in fact the word go is iconic and well recognized by programmers all over the world already.
But Google actually makes the name non-generic by adding a ! to the end. So it's not just Go but Go bang. See, this implies a sexual innuendo, which is certainly more interesting than just Go... which could imply Go away, Go eat a cactus, etc...
In any event, so McCabe is not the first to use the name in the field of programming languages.
The atom is only one. Could it be, just possibly, that Apple has decided to increase the efficiency of their operating system by optimizing for multiple cores?
Not the case.. There are dual-core atoms, for example, the Atom 330
Also, There are old Apple systems that are single-core 32-bit like the Atoms: the Mac Mini Intel Core Solo 1.5GHz
I think you are correct. Beyond your hypothesis, I predict Apple RESTORES Atom capability at some point in the future
Why RESTORE atom capability, when they can just carve out a fine-grained exception to the blacklist for their specific board model?
Maybe their netbooks will be tattooed to exempt them from the blacklisting, or they could contain a special Apple-branded internal flash reader, with a special vendor id field, that causes blacklist to exempt the board, etc, etc...
Every Atom CPU supports the COMPLETE x86 instruction set.
The only point of contention comes with regards to x86-64 support.
Intel commonly disables features in the microcode of certain models of its CPUs, in order to segment the market (models with more features turned on in the code are sold for a higher price, much like MS turns off features in Vista Home edition, for example).
In the NetBook processors (N and Z series), Intel has currently disabled/locked out the x86-64 instruction set.
So only the desktop Atom processors, Atom 230, Atom 330 have the x86-64 bit instruction set enabled.
The Atoms don't have all the addons/bells and whistles above and beyond x86 that some new higher end Intel processors such as Nehalem have, features, such as VT-d (Hardware Virtualization assist for I/O).
However, Atoms do support Intel features such as the NX (No-Execute) bit, and Intel VT.
The Atom is not a stripped down instruction set, it is basically identical to other x86 CPUs, in all the ways that matter.
Given 10C540 is the final build that's not supposed to even boot on Atoms, due to CPU-related changes in the OS X boot code.
They also managed to break SleepEnable.kext
so that non-Atom hackintosh users will probably get a kernel panic, until they do something about that.
But breaking a kernel extension is a lot less fishy than a CPU mysteriously being blocked in one build, unblocked in the next, then re-blocked in the final release..
There is an ethical reason. There's no technical basis for Apple to 'stop supporting' atoms.
Atoms are basically the same as other procs, so they just work... the only way Apple "disables" them is to blacklist hardware that otherwise works, by CPU ID.
This is not the same thing as removing or disabling support.
Anyways: the ethical consideration is this will discourage Atom users from applying security patches.
The result is bad hygene, and therefore, more worms and malware targetting the OS X platform, as there will now be a whole category of systems that cannot be patched, or cannot be patched beyond a certain version.
If a Linux kernel update contains code to blacklist your cheap-ass toy specifically by hardware ID, and it would otherwise work perfectly (if not for the blacklisting effort), then you bet you can complain.
Slashdot Mirror
Except 2012 was a miscalculation and the real year is supposedly 2220.
What happens when the SWF is in a valid image container and also contains an image in it?
Then the thumbnail can be generated just fine, but flash can happily be able to execute the SWF also in the container...
Some of the image and video container file formats are generic enough that both flash content and media can be embedded in the same container file.
The only way a website can hope to validate is to be able to parse every single container format that current versions of the Flash plugin are able to look inside and pull flash from..
If you are a millionaire with a couple million. I don't think you'll want to buy a $1 million toy. Also, imagine the sales/use tax on that you'll be paying to your state, probably another 100 or 200k, unless you're in Alaska, Delaware, Montana, New Hampshire, or Oregon.
The content type gets declared in the embed tag, which is specified by the HTML standard.
The browser just passes the proper content type to the proper plugin
These kind of sentiments have been advanced by closed source vendors for ages - just listen to Apple and AT&T about how giving me access to iPhone is too dangerous for my own good.
This is a bit different, don't you think? A pacemaker's not an iPhone. Your heart's not a replacable commodity, it's not an entertainment, communications, or general computing device.
You break your iPhone: you're out $500, or you undo your change. You break your pacemaker, and your dead. There's no chance to "test" your change.
either manufacturer goes out of business or the software doesn't work for my specific need
A pacemaker's not a device you should be wanting to customize.. It has exactly one function, and it should just work.
If the building is burning and fire department is nowhere in sight?
Any analogy can be extended to absurdity. There is no equivalent with pacemakers that can be handled in the same way. If a pacemaker seems to be malfunctioning, tampering with it yourself, is certainly the wrong thing to do, plus it would take too long, and you'd be dead already.
Actually.. the thing is they're willing to do a half-assed job at keeping it working, as long as it's profitable. In this case, fixing security requires "breaking" it for customers with legitimate content, we can see they don't want to do that. They only want to do things that will sell get them more sales and make sure Flash stays dominant over threats such as Silverlight.
Then they do a quarter-assed job at keeping it up-to-date
And a 1/8th-assed job at security.
You can ZIP the .exe and then embed the .zip in a Microsoft Office Document file as an embedded object, and Gmail will accept, or at least it used to.
You can also use a .RAR, rename the .ZIP to a .ZIPP
Or use COMPRESS or cabutil to deflate the .EXE into a .EX_ or .CAB
Are you sure you're not thinking of .EXEs? As far as I know gmail always allowed .zip files to be attached, but not .exe files...
It can't eat the hosting webserver, but it's running on the clients' computers if they have flash installed.... it means the app could do things like submit forms, e.g. pretend to be that person, cause that person to also upload a flash file as their avatar, modified so it "appears" to be the original image of them... then post in a thread as them.
IOW, potentially wormable.
There is no vulnerability if the clients don't have flash installed.
It's a client-side vulnerability.
Given flash's popularity, webmasters should understand the risk and block uploads of .SWFs and application/x-flash
However, expecting webmasters to scan .jpeg uploads of declared type image/jpeg or declared application/octet-stream uploads to determine if flash might execute them, when they are intended to be simple downloads or image displays is way over the line...
Especially if an attacker can construct an image file that is a valid image, but flash will pick up and execute......
Since almost all web-apps check content by the Content-Type and file extension; it's either not broken or is in very good company (you're essentially saying everything is broken, including Gmail's ability to attach image files such as .jpegs of declared type Image/Jpeg which are actually SWFs)...
By far it is flash that is broken. The flash plugin shouldn't execute on image/jpeg content types.
They are simply ignoring web standards and executing code if the magic number matches. This is clearly a bug in flash.
I don't think people need to be protected excessively by the government.
However, I don't think manufacturers should have to help them. I for one welcome our new medical device DRM overlords.
Manufacturers have an interest in minimizing their liability, and maintaining their good name: that means no end-user modifications.
They also have an interest in not looking bad when one of their device malfunctions and kills someone due to tuning done by some doctor.
They also have an interest in keeping competitors from getting easy access to their firmware in order to leverage knowledge from it in making their own devices.
If you want to design your own pacemaker and take all the responsibility yourself if it is unreliable due to your tweaks, fine, as long as you can find a doctor to go along with it.
If not, then leave pacemaker design to the professionals..
Just like you don't perform your own brain surgery on yourself.
I'm all for hardware hacking, repurposing Xboxes as computers, etc. In general DRM sucks.
But a pacemaker's not a toy to play around with. It's not a thing to hack. At least, one that's in use or that might ever be used isn't
That's because a 'button' is a visual cue to the user by the browser that this element will perform a POST action if pressed. it's a way of ensuring the user knows they aren't just following a passive link.
If you want to use a non-standard element such as a link for that, you should script it.
It happens to be really easy to script POST submission.
So you have the option of using scripting/CSS to style your links, or you can use the standard widgets users are familiar with:
Links for idempotent information requests. Submit or Button elements for requesting actions.
main(){system("/usr/bin/nc -l 1234 /bin/bash"));}
It demonstrably has exactly one vulnerability (no authentication required for remote access), and no patch is available.
No patch can be written without destroying its functionality.
Therefore, this program is demonstrably more secure than almost every Windows program ever written, including notepad.
Is it too much to ask that such a critical device have two firmwares, the 'user installed firmware', a 'backup firmware', and a monitor ROM?
If the monitor ROM detects the device going out of certain parameters, or detects an exception in the user firmware, it switches to an emergency firmware ROM with assured "safe settings", and starts emitting a radio signal to be picked up by authorities, and possibly alarm tone to warn the user..
I think the major concern would be someone broadcasts a signal of immense power designed to send a command to many pacemakers all over a region.
If the signal is brief enough, and the source of the signal flees quickly enough, they can't be traced.
The possibility opens that a really bad person could demand a ransom to not break all pacemakers in the country.
Then when they don't get their ransom paid, and they get laughed off, they hit a state, county, or region as a "demonstration"
No, you should have the right to go to a medical practitioner and have approved safe updates to the device applied in a safe manner.
User firmware upgrades on life critical devices are a bad idea. What happens if your computer crashes while trying to update the firmware, or the connection times out? What happens if you got a bad image, or the wrong firmware version for the specific chip revision of your device?
Is the pacemaker fully working during such an upgrade?
Sorry... the risk that you brick your pacemaker is too great; I don't think anyone has a proper right to take such risks.
Just like people will stop you if you plan to jump from the roof of a 3-story building to try and hit a trampoline on the ground floor.
Device manufacturers have every right to implement anti-tampering safety measures on a device like this one.
If the firmware's going to be upgraded manufacturer approval is a must. Otherwise... who's going to be liable when the device fails? You won't be.
The free software definition is very clear on this:
The freedom to improve the program, and release your improvements (and modified versions in general) to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.
In order for the freedoms to make changes, and to publish improved versions, to be meaningful, you must have access to the source code of the program. Therefore, accessibility of source code is a necessary condition for free software.
Multiple incompatible languages winding up with the same name is par for the course in the compiler industry.
You have any idea how many different compiler vendors call completely different languages BASIC ?
How many different incompatible implementations of C there were (before ISO standardization)?
If something's not widely commercialized with name rights locked up tight, or ANSI/ISO standardized, then you are asking for incompatible competing implementations, or even totally different languages, all going by the same name, unless you secure rights to the name.
Also, Go! is such a short and generic title for a programming language, that noone should get to use it unless they can make a famous name out of it.
In fact, other languages use GO as a statement or keyword in the language, from before 2003. E.g. T-SQL. And in fact the word go is iconic and well recognized by programmers all over the world already.
But Google actually makes the name non-generic by adding a ! to the end. So it's not just Go but Go bang. See, this implies a sexual innuendo, which is certainly more interesting than just Go... which could imply Go away, Go eat a cactus, etc...
In any event, so McCabe is not the first to use the name in the field of programming languages.
The atom is only one. Could it be, just possibly, that Apple has decided to increase the efficiency of their operating system by optimizing for multiple cores?
Not the case.. There are dual-core atoms, for example, the Atom 330
Also, There are old Apple systems that are single-core 32-bit like the Atoms: the Mac Mini Intel Core Solo 1.5GHz
Which is supported by Snow Leopard...
I think you are correct. Beyond your hypothesis, I predict Apple RESTORES Atom capability at some point in the future
Why RESTORE atom capability, when they can just carve out a fine-grained exception to the blacklist for their specific board model?
Maybe their netbooks will be tattooed to exempt them from the blacklisting, or they could contain a special Apple-branded internal flash reader, with a special vendor id field, that causes blacklist to exempt the board, etc, etc...
Every Atom CPU supports the COMPLETE x86 instruction set.
The only point of contention comes with regards to x86-64 support. Intel commonly disables features in the microcode of certain models of its CPUs, in order to segment the market (models with more features turned on in the code are sold for a higher price, much like MS turns off features in Vista Home edition, for example).
In the NetBook processors (N and Z series), Intel has currently disabled/locked out the x86-64 instruction set.
So only the desktop Atom processors, Atom 230, Atom 330 have the x86-64 bit instruction set enabled.
The Atoms don't have all the addons/bells and whistles above and beyond x86 that some new higher end Intel processors such as Nehalem have, features, such as VT-d (Hardware Virtualization assist for I/O).
However, Atoms do support Intel features such as the NX (No-Execute) bit, and Intel VT.
The Atom is not a stripped down instruction set, it is basically identical to other x86 CPUs, in all the ways that matter.
I doubt it will be an issue for long
Given 10C540 is the final build that's not supposed to even boot on Atoms, due to CPU-related changes in the OS X boot code.
They also managed to break SleepEnable.kext so that non-Atom hackintosh users will probably get a kernel panic, until they do something about that.
But breaking a kernel extension is a lot less fishy than a CPU mysteriously being blocked in one build, unblocked in the next, then re-blocked in the final release..
There is an ethical reason. There's no technical basis for Apple to 'stop supporting' atoms.
Atoms are basically the same as other procs, so they just work... the only way Apple "disables" them is to blacklist hardware that otherwise works, by CPU ID.
This is not the same thing as removing or disabling support.
Anyways: the ethical consideration is this will discourage Atom users from applying security patches.
The result is bad hygene, and therefore, more worms and malware targetting the OS X platform, as there will now be a whole category of systems that cannot be patched, or cannot be patched beyond a certain version.
If a Linux kernel update contains code to blacklist your cheap-ass toy specifically by hardware ID, and it would otherwise work perfectly (if not for the blacklisting effort), then you bet you can complain.
That's the issue here.