Image Magic server-jacking
- prehistoric
- Posts: 1744
- Joined: Tue 23 Oct 2007, 17:34
Image Magic server-jacking
This is not necessarily specific to Puppy, but I want to caution people who have Image Magick installed and run as root. It is possible to embed commands in a picture file in a way that will cause them to be executed if the file is manipulated with ImageMagick.
I suspect some sites offering free high-resolution pictures with a lot skin are exploiting this vulnerability. If you identify such a booby-trapped picture, and notify a site, it would be interesting to see what changes as a result. Any site which fails to correct this should be assumed hostile.
Someone who spends more time building image processing software than I do should chime in if they have examples of image viewing or processing software which incorporates ImageMagick without mentioning the name. It is also possible to copy code without explicitly including ImageMagic packages. I've seen vulnerabilities from commands passed via shell scripts or variables before, some of these are real doozies.
I suspect some sites offering free high-resolution pictures with a lot skin are exploiting this vulnerability. If you identify such a booby-trapped picture, and notify a site, it would be interesting to see what changes as a result. Any site which fails to correct this should be assumed hostile.
Someone who spends more time building image processing software than I do should chime in if they have examples of image viewing or processing software which incorporates ImageMagick without mentioning the name. It is also possible to copy code without explicitly including ImageMagic packages. I've seen vulnerabilities from commands passed via shell scripts or variables before, some of these are real doozies.
thanks
prehistoric,
Thanks for the headsup. I have Image Magick on one of main Linux (non-puppy) machines, and though it doesn't have or can't get (that I know of) root access, I nevertheless just now completely removed it. I've also wondered about pictures and code-embedded in them, and have read about it before. Picture-embedding code can apply to anything, not just adult-material sites, when you think about it.
Thanks for the headsup. I have Image Magick on one of main Linux (non-puppy) machines, and though it doesn't have or can't get (that I know of) root access, I nevertheless just now completely removed it. I've also wondered about pictures and code-embedded in them, and have read about it before. Picture-embedding code can apply to anything, not just adult-material sites, when you think about it.
- Dingo
- Posts: 1437
- Joined: Tue 11 Dec 2007, 17:48
- Location: somewhere at the end of rainbow...
- Contact:
Since a lot of years I completely migrated to Graphicsmagick; faster and using fewer resources
Can we assume Graphicsmagick is safe?
Can we assume Graphicsmagick is safe?
replace .co.cc with .info to get access to stuff I posted in forum
dropbox 2GB free
OpenOffice for Puppy Linux
dropbox 2GB free
OpenOffice for Puppy Linux
- prehistoric
- Posts: 1744
- Joined: Tue 23 Oct 2007, 17:34
- prehistoric
- Posts: 1744
- Joined: Tue 23 Oct 2007, 17:34
I'm not familiar with uextract, which I had been assuming only worked with explicit archives. Could you give us an example? Since I'm currently running Fatdog 702 I'd like to see how is works on a normal Pupplet before I go through experiments on extracting the code and seeing what it does on a system which doesn't use .pet packages.don570 wrote:I believe uextract can extract this info from the picture ...
Added: once we have a convenient test for code embedded in pictures this might be a good thread to report where you find such crap.
- prehistoric
- Posts: 1744
- Joined: Tue 23 Oct 2007, 17:34
Another correspondent gave me the standard "this couldn't happen with Windows" response. I'll admit that you can't run Unix/Linux shell scripts on Windoze boxes, unless they already have a command interpreter which translates sh commands to Windows cli commands. You might be surprised to discover which cheap software on Windows has been implemented via this approach. You only need to compromise a machine via a single such application.
More generally, multiple vulnerabilities in Windows from active objects are possible. There have been several generations of active objects, each with its own defects.
Still, this falls short of the potential to embed malicious javascript in pictures. But, who uses javascript? More sophisticated attacks take place on Twitter. But, who uses Twitter?
Now do you see why my browser runs in a restricted environment?
More generally, multiple vulnerabilities in Windows from active objects are possible. There have been several generations of active objects, each with its own defects.
Still, this falls short of the potential to embed malicious javascript in pictures. But, who uses javascript? More sophisticated attacks take place on Twitter. But, who uses Twitter?
Now do you see why my browser runs in a restricted environment?
- prehistoric
- Posts: 1744
- Joined: Tue 23 Oct 2007, 17:34
Hi Musher,
I don't know of any special vulnerabilities there. The problem comes from two aspects: 1) the image processing routines are strung together with shell commands; 2) nowhere in this does anyone check that a file with any extension that declares it to be a picture consists of that and nothing else. This is a really boneheaded combination, and I'm surprised nobody caught it a long time ago.
Even the Graphics Magick package derived from Image Magick has closed this vulnerability. I am less informed about sneaky ways to embed javascript in images, but then I assume anytime I run code from an outside source on the Internet we are playing the game deuces wild. The extent to which browsers, video players, slideshows, etc. will accept mangled code has long been used to hijack machines, and nothing about this seems subject to a fundamental improvement because advertising done this way is a primary source of funding for web sites. Make it too easy to block and people will turn off the code that does things they don't like. Most advertising is only funny once.
I can still remember the time back in the 1980s when a colleague showed me a clever Word macro which changed the behavior of his machine for word processing. I went to the manual (still on paper at the time) and checked that one of these allowed it to write to files. I could even see ways to execute arbitrary code. I didn't tell anyone, because I knew some of those I worked with would exploit this, and I didn't have time to devote to cleaning up the resulting mess. It was a year before I saw the exploit I imagined in the news. It took longer for people to figure out that Excel macros were computationally universal. Compared to some of the problems in computability theory showing that universal is child's play. Every time someone designs a special-purpose language which stops short of being Turing complete someone else adds a feature which pushes it over the edge. In computer graphics hardware you can find the subject described in Ivan Sutherland's prescient Great Wheel of Karma talk. The level of complexity seen in huge piles of interpreters needed to use the multitude of things on the Internet certainly seems more in keeping with Eastern philosophy and religion than the spare and allegedly rational roots of Western technology.
It's a jungle out there.
I don't know of any special vulnerabilities there. The problem comes from two aspects: 1) the image processing routines are strung together with shell commands; 2) nowhere in this does anyone check that a file with any extension that declares it to be a picture consists of that and nothing else. This is a really boneheaded combination, and I'm surprised nobody caught it a long time ago.
Even the Graphics Magick package derived from Image Magick has closed this vulnerability. I am less informed about sneaky ways to embed javascript in images, but then I assume anytime I run code from an outside source on the Internet we are playing the game deuces wild. The extent to which browsers, video players, slideshows, etc. will accept mangled code has long been used to hijack machines, and nothing about this seems subject to a fundamental improvement because advertising done this way is a primary source of funding for web sites. Make it too easy to block and people will turn off the code that does things they don't like. Most advertising is only funny once.
I can still remember the time back in the 1980s when a colleague showed me a clever Word macro which changed the behavior of his machine for word processing. I went to the manual (still on paper at the time) and checked that one of these allowed it to write to files. I could even see ways to execute arbitrary code. I didn't tell anyone, because I knew some of those I worked with would exploit this, and I didn't have time to devote to cleaning up the resulting mess. It was a year before I saw the exploit I imagined in the news. It took longer for people to figure out that Excel macros were computationally universal. Compared to some of the problems in computability theory showing that universal is child's play. Every time someone designs a special-purpose language which stops short of being Turing complete someone else adds a feature which pushes it over the edge. In computer graphics hardware you can find the subject described in Ivan Sutherland's prescient Great Wheel of Karma talk. The level of complexity seen in huge piles of interpreters needed to use the multitude of things on the Internet certainly seems more in keeping with Eastern philosophy and religion than the spare and allegedly rational roots of Western technology.
It's a jungle out there.
Hello again prehistoiric.
A thought about your #2 above: could we not check the type of file with the < file >
utility?
I did a little test with an agenda file in plain text format and this is what I got:
As I said, just a thought. BFN.
A thought about your #2 above: could we not check the type of file with the < file >
utility?
I did a little test with an agenda file in plain text format and this is what I got:
It didn't matter that I changed the extension, the < file > utility still caught it as a text file.[~]>ls -Algot my-documents/05_m*.txt
-rw------- 1 531 mai 5 15:15 my-documents/05_mai_2016.txt
[~]>file -pb my-documents/05_m*.txt
UTF-8 Unicode text
[~]>cp my-documents/05_mai_2016.txt my-documents/05_mai_2016.jpg
[~]>file -pb my-documents/05_m*.jpg
UTF-8 Unicode text
As I said, just a thought. BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
- prehistoric
- Posts: 1744
- Joined: Tue 23 Oct 2007, 17:34
File ought to catch the change, but I'd like to see that it catches a file which really starts with an image. I know I've seen errors in confusing situations. Once people set out deliberately to confuse scripts the problem becomes more difficult. Tolerance for common errors out on the Internet is the loophole through which all kinds of exploits take place.
Nothing untoward happens.musher0 wrote:What happens if you process such a picture with one of the NetPbm utilities (included in most new Puppies) or with mtpaint?
Netpbm has exactly one program for handling unknown filetypes: 'anytopnm' which asks 'file' what the file is, and launches type-specific converter based on that.
mtPaint detects filetypes through signatures, and whatever it opens as image can never become input to its script interpreter.
So scripts, however disguised, cannot do anything.
What happened is just another practical demonstration that programs should NOT run scripts automagically.
A valid cause for concern would be if one of major file-format libs (libpng, libjpeg, libgif, libtiff, libjasper, libopenjpeg) got a code-execution exploit instead.