Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.linux > #51566 > unrolled thread

A problem with "convert" - security related

Back to article view | Back to alt.os.linux

Contents

  A problem with "convert" - security related Paulo da Silva <p_s_d_a_s_i_l_v_a_ns@netcabo.pt> - 2018-11-10 02:35 +0000
    Re: A problem with "convert" - security related Paul <nospam@needed.invalid> - 2018-11-10 00:15 -0500
    Re: A problem with "convert" - security related stepore <linshine@here.now> - 2018-11-10 00:34 -0800
      Re: A problem with "convert" - security related Paul <nospam@needed.invalid> - 2018-11-10 07:32 -0500
      Re: A problem with "convert" - security related Paulo da Silva <p_s_d_a_s_i_l_v_a_ns@netcabo.pt> - 2018-11-10 17:19 +0000
        Re: A problem with "convert" - security related Paul <nospam@needed.invalid> - 2018-11-10 17:03 -0500
          Re: A problem with "convert" - security related Paulo da Silva <p_s_d_a_s_i_l_v_a_ns@netcabo.pt> - 2018-11-11 02:45 +0000
            Re: A problem with "convert" - security related Paul <nospam@needed.invalid> - 2018-11-10 23:26 -0500
              Re: A problem with "convert" - security related "Carlos E. R." <robin_listas@es.invalid> - 2018-11-12 14:17 +0100
                Re: A problem with "convert" - security related Paul <nospam@needed.invalid> - 2018-11-12 09:21 -0500
                  Re: A problem with "convert" - security related "Carlos E. R." <robin_listas@es.invalid> - 2018-11-12 17:09 +0100

#51566 — A problem with "convert" - security related

Hello.

Some times (not too frequently) I need to use a command like
convert *.png foo.pdf.

This converts a bunch of images into a pdf book.

Last time I tried it, I got an error:
convert-im6.q16: not authorized `foo.pdf' @
error/constitute.c/WriteImage/1037.

I could see that this has to do with "restrictions" in the file
/etc/ImageMagick-6/policy.xml

Some line there seems to prevent writing to pdf files!
(I am aware that I can comment that line).

I just temporarily removed that file and successfully executed the command.

What is the related security problem?
After all this is a read/write command!

BTW, in which risks do I incur just removing the file?

Thanks
Paulo

[toc] | [next] | [standalone]

#51567

Paulo da Silva wrote:
> Hello.
> 
> Some times (not too frequently) I need to use a command like
> convert *.png foo.pdf.
> 
> This converts a bunch of images into a pdf book.
> 
> Last time I tried it, I got an error:
> convert-im6.q16: not authorized `foo.pdf' @
> error/constitute.c/WriteImage/1037.
> 
> I could see that this has to do with "restrictions" in the file
> /etc/ImageMagick-6/policy.xml
> 
> Some line there seems to prevent writing to pdf files!
> (I am aware that I can comment that line).
> 
> I just temporarily removed that file and successfully executed the command.
> 
> What is the related security problem?
> After all this is a read/write command!
> 
> BTW, in which risks do I incur just removing the file?
> 
> Thanks
> Paulo

Go down to line 1037.

https://github.com/ImageMagick/ImageMagick/blob/master/MagickCore/constitute.c

      char filename[MagickPathExtent];

My guess is, there's something wrong with the path for
the output and how you're specifying it.

How about

    convert "*.png" foo.pdf

in an attempt to fool it into having two arguments
on the command line.

Or even re-formulate the command and try again.
Say I have three PNG files. Try this

    convert 1.png 2.png 3.png foo.pdf

and see what error is returned.

You might want to try

    convert -h
    convert --help
    ...

the usual help formulations, then check how
you're supposed to use the command. In some cases,
you might be using documentation for a different version
and they changed something.

I would contemplate a more complicated theory, once
you've checked the obvious.

Like, make it do any command and be successful, as a start.
And work your way up from there. You could, for example,
run convert then pipe it to some other command, to "display"
the result. In an attempt to avoid the filename issue, whatever
it is.

    Paul

[toc] | [prev] | [next] | [standalone]

#51570

On 11/09/2018 06:35 PM, Paulo da Silva wrote:

> I could see that this has to do with "restrictions" in the file
> /etc/ImageMagick-6/policy.xml
> 
> Some line there seems to prevent writing to pdf files!
> (I am aware that I can comment that line).
> 
> I just temporarily removed that file and successfully executed the command.
> 

Don't remove the file, just change this bit:
<policy domain="coder" rights="read | write" pattern="PDF" />

[toc] | [prev] | [next] | [standalone]

#51572

stepore wrote:
> On 11/09/2018 06:35 PM, Paulo da Silva wrote:
> 
>> I could see that this has to do with "restrictions" in the file
>> /etc/ImageMagick-6/policy.xml
>>
>> Some line there seems to prevent writing to pdf files!
>> (I am aware that I can comment that line).
>>
>> I just temporarily removed that file and successfully executed the 
>> command.
>>
> 
> Don't remove the file, just change this bit:
> <policy domain="coder" rights="read | write" pattern="PDF" />

I fired up Mint 19, and the lines are missing.
Mint 19 works properly, without editing the file.

While Ubuntu 1804 has PDF switched off.

    Paul

[toc] | [prev] | [next] | [standalone]

#51573

Às 08:34 de 10/11/18, stepore escreveu:
> On 11/09/2018 06:35 PM, Paulo da Silva wrote:
> 
> 
> Don't remove the file, just change this bit:
> <policy domain="coder" rights="read | write" pattern="PDF" />

Yes, I know how to possibly fix it. I just removed that file to speed
things up for just a single command.
My problem is mainly to understand what are the risks of such utility
(convert) for having those restrictions in the policy file.
In particular, why is (or may be) it "dangerous" allowing write to pdf
files!
Knowing that I'll try a more definitive solution.

I'm assuming that the guy(s) who wrote those rules are not crazy :-)

[toc] | [prev] | [next] | [standalone]

#51574

Paulo da Silva wrote:
> Às 08:34 de 10/11/18, stepore escreveu:
>> On 11/09/2018 06:35 PM, Paulo da Silva wrote:
>>
>>
>> Don't remove the file, just change this bit:
>> <policy domain="coder" rights="read | write" pattern="PDF" />
> 
> Yes, I know how to possibly fix it. I just removed that file to speed
> things up for just a single command.
> My problem is mainly to understand what are the risks of such utility
> (convert) for having those restrictions in the policy file.
> In particular, why is (or may be) it "dangerous" allowing write to pdf
> files!
> Knowing that I'll try a more definitive solution.
> 
> I'm assuming that the guy(s) who wrote those rules are not crazy :-)

The reference to Ghostscript, comes from the ability to modify
files in the file system using PostScript.

The fix many years ago, was to add a parameter to the command
line for a gs run, which would prevent that. The scripts that come
with the GhostScript package, have been using that parameter
for more than ten years.

There should be no danger creating a file, as when Imagemagick
does it. If Imagemagick calls an already-installed gs, one with
compromised files in the installation, then just about anything
could happen. (This is true of doing anything on a computer.
Maybe my copy of "listdir" has been modified by a bad actor...)

When you run "convert", you're not running it elevated,
so from a process point of view, the risk should be smaller.
It should not be able to modify anything in the root account
directory.

*******

https://www.mankier.com/1/gs

    Safer Mode

    The -dSAFER option disables the "deletefile" and "renamefile"
    operators and prohibits opening piped commands ("%pipe%cmd") ...

These would be issues with later usage of .ps or .pdf files,
and how any viewer or printing process handles documents.

In general, since PDF can also contain Javascript, there is
more than one attack surface present. In Acrobat (reader), there is
a tick box to turn off support for Javascript when viewing PDFs.

The PDF that "convert" makes, should be a pretty simple construct,
as all it needs to do is make an image stream from the image file,
and place page information around the top and bottom of the
page definition. There should be nothing about the file itself
which is dangerous.

HTH,
     Paul

[toc] | [prev] | [next] | [standalone]

#51575

Às 22:03 de 10/11/18, Paul escreveu:
> Paulo da Silva wrote:
>> Às 08:34 de 10/11/18, stepore escreveu:
>>> On 11/09/2018 06:35 PM, Paulo da Silva wrote:
>>>
>>>
...
>> My problem is mainly to understand what are the risks of such utility
>> (convert) for having those restrictions in the policy file.
>> In particular, why is (or may be) it "dangerous" allowing write to pdf
>> files!
...

> 
> The reference to Ghostscript, comes from the ability to modify
> files in the file system using PostScript.
> 
> The fix many years ago, was to add a parameter to the command
> line for a gs run, which would prevent that. The scripts that come
> with the GhostScript package, have been using that parameter
> for more than ten years.
> 
> There should be no danger creating a file, as when Imagemagick
> does it. If Imagemagick calls an already-installed gs, one with
> compromised files in the installation, then just about anything
> could happen. (This is true of doing anything on a computer.
> Maybe my copy of "listdir" has been modified by a bad actor...)
> 
> When you run "convert", you're not running it elevated,
> so from a process point of view, the risk should be smaller.
> It should not be able to modify anything in the root account
> directory.
> 
> *******
> 
> https://www.mankier.com/1/gs
> 
>    Safer Mode
> 
>    The -dSAFER option disables the "deletefile" and "renamefile"
>    operators and prohibits opening piped commands ("%pipe%cmd") ...
> 
> These would be issues with later usage of .ps or .pdf files,
> and how any viewer or printing process handles documents.
> 
> In general, since PDF can also contain Javascript, there is
> more than one attack surface present. In Acrobat (reader), there is
> a tick box to turn off support for Javascript when viewing PDFs.
> 
> The PDF that "convert" makes, should be a pretty simple construct,
> as all it needs to do is make an image stream from the image file,
> and place page information around the top and bottom of the
> page definition. There should be nothing about the file itself
> which is dangerous.
> 
If I correctly read your post I think that those issues only occur
during reads, not creating/writing new pdf's from images.

Thanks

[toc] | [prev] | [next] | [standalone]

#51576

Paulo da Silva wrote:
> Às 22:03 de 10/11/18, Paul escreveu:
>> Paulo da Silva wrote:
>>> Às 08:34 de 10/11/18, stepore escreveu:
>>>> On 11/09/2018 06:35 PM, Paulo da Silva wrote:
>>>>
>>>>
> ...
>>> My problem is mainly to understand what are the risks of such utility
>>> (convert) for having those restrictions in the policy file.
>>> In particular, why is (or may be) it "dangerous" allowing write to pdf
>>> files!
> ...
> 
>> The reference to Ghostscript, comes from the ability to modify
>> files in the file system using PostScript.
>>
>> The fix many years ago, was to add a parameter to the command
>> line for a gs run, which would prevent that. The scripts that come
>> with the GhostScript package, have been using that parameter
>> for more than ten years.
>>
>> There should be no danger creating a file, as when Imagemagick
>> does it. If Imagemagick calls an already-installed gs, one with
>> compromised files in the installation, then just about anything
>> could happen. (This is true of doing anything on a computer.
>> Maybe my copy of "listdir" has been modified by a bad actor...)
>>
>> When you run "convert", you're not running it elevated,
>> so from a process point of view, the risk should be smaller.
>> It should not be able to modify anything in the root account
>> directory.
>>
>> *******
>>
>> https://www.mankier.com/1/gs
>>
>>    Safer Mode
>>
>>    The -dSAFER option disables the "deletefile" and "renamefile"
>>    operators and prohibits opening piped commands ("%pipe%cmd") ...
>>
>> These would be issues with later usage of .ps or .pdf files,
>> and how any viewer or printing process handles documents.
>>
>> In general, since PDF can also contain Javascript, there is
>> more than one attack surface present. In Acrobat (reader), there is
>> a tick box to turn off support for Javascript when viewing PDFs.
>>
>> The PDF that "convert" makes, should be a pretty simple construct,
>> as all it needs to do is make an image stream from the image file,
>> and place page information around the top and bottom of the
>> page definition. There should be nothing about the file itself
>> which is dangerous.
>>
> If I correctly read your post I think that those issues only occur
> during reads, not creating/writing new pdf's from images.
> 
> Thanks

I agree it doesn't make any sense. Not on writes.
It's a reading/interpreting issue.

One of the reasons these capabilities existed in the first
place, is some laser printers had "resident" fonts. These
may have been stored on a hard drive inside the laser printer.
At the time, flash (NOR) memory was too expensive to hold
the fonts.

You could send a specially formulated .ps print job, to send
a font to the printer. I've never done it, but heard you
could do such a thing at the time.

Some file capabilities existed in PostScript, that might not
have been there, if it wasn't for the printer requirement.

Today, we send embedded fonts in documents, so a printer
with resident fonts isn't as necessary. The embedded font
is a subset. I have document samples here, where a font table
only has one character in it, as an example of how few characters
they're willing to embed when sending them with the document.

    Paul

[toc] | [prev] | [next] | [standalone]

#51577

On 11/11/2018 05.26, Paul wrote:
> Paulo da Silva wrote:

...

> I agree it doesn't make any sense. Not on writes.
> It's a reading/interpreting issue.
> 
> One of the reasons these capabilities existed in the first
> place, is some laser printers had "resident" fonts. These
> may have been stored on a hard drive inside the laser printer.
> At the time, flash (NOR) memory was too expensive to hold
> the fonts.
> 
> You could send a specially formulated .ps print job, to send
> a font to the printer. I've never done it, but heard you
> could do such a thing at the time.
> 
> Some file capabilities existed in PostScript, that might not
> have been there, if it wasn't for the printer requirement.
> 
> Today, we send embedded fonts in documents, so a printer
> with resident fonts isn't as necessary. The embedded font
> is a subset. I have document samples here, where a font table
> only has one character in it, as an example of how few characters
> they're willing to embed when sending them with the document.

All printers, even ribbon printers (pin matrix), have "fonts" :-)

In some form. They need to handle fonts in order to be able to print
plain ascii.

Well, maybe winprinters don't, I do not know.

Postscript printers have more sophisticated fonts. They can be scaled
(vector based?) and you do not see the "dots", the quality normally
keeps. Similarly I think PDF printers also have some fonts, because the
PDF format assumes the receiver knows how to handle a small set of
fonts. You can try print directly (raw) a PDF without embedded fonts and
it should print.

My printer handles ps and I can send it plain ps files without sending
fonts and they print fine.

-- 
Cheers,
       Carlos E.R.

[toc] | [prev] | [next] | [standalone]

#51578

Carlos E. R. wrote:
> On 11/11/2018 05.26, Paul wrote:
>> Paulo da Silva wrote:
> 
> ...
> 
>> I agree it doesn't make any sense. Not on writes.
>> It's a reading/interpreting issue.
>>
>> One of the reasons these capabilities existed in the first
>> place, is some laser printers had "resident" fonts. These
>> may have been stored on a hard drive inside the laser printer.
>> At the time, flash (NOR) memory was too expensive to hold
>> the fonts.
>>
>> You could send a specially formulated .ps print job, to send
>> a font to the printer. I've never done it, but heard you
>> could do such a thing at the time.
>>
>> Some file capabilities existed in PostScript, that might not
>> have been there, if it wasn't for the printer requirement.
>>
>> Today, we send embedded fonts in documents, so a printer
>> with resident fonts isn't as necessary. The embedded font
>> is a subset. I have document samples here, where a font table
>> only has one character in it, as an example of how few characters
>> they're willing to embed when sending them with the document.
> 
> All printers, even ribbon printers (pin matrix), have "fonts" :-)
> 
> In some form. They need to handle fonts in order to be able to print
> plain ascii.
> 
> Well, maybe winprinters don't, I do not know.
> 
> Postscript printers have more sophisticated fonts. They can be scaled
> (vector based?) and you do not see the "dots", the quality normally
> keeps. Similarly I think PDF printers also have some fonts, because the
> PDF format assumes the receiver knows how to handle a small set of
> fonts. You can try print directly (raw) a PDF without embedded fonts and
> it should print.
> 
> My printer handles ps and I can send it plain ps files without sending
> fonts and they print fine.
> 

There's a couple ways to print.

The "clumsy" way, is to send a bitmap or pixmap
image of what is to be printed. This usually takes
a bit of bandwidth (but not by todays standards). Back
in the day, we had some pretty bad LAN standards.

The first laser we had at work, didn't have an internal
interpreter. It was a "dumb" printer. It had what
is known as a "video interface". The card feeding it,
sent a 2Mbit/sec video signal. The "image" was then
drawn on the drum as the drum rotated. Print jobs
sent to such a printer, consisted of bitmaps, and
the driver on the computer sitting next to the printer,
would send them out via the video interface.

Later printers, used higher level languages, like
PostScript or PCL or whatever. The printer has
a parser, to read the more compact representation
of a print job, and convert to a bitmap. (One of the
printers had a 25MHz processor, a RISC.) On some
of those printers, the printer didn't have enough
RAM to hold the whole sheet of paper. This
meant that the RAM functioned as a "fraction-of-a-page
buffer". And the parser had to stay ahead of the
print rate, to keep the buffer full. Only rich
companies could afford to put more RAM in the
printer, so an entire glorious page could be
held in RAM. Some of those first machines were
that cheesy.

It's those processor-equipped machines, that
might have a hard drive with fonts. It was an option.
It also means you could make very compact print
jobs. You could tell the interpreter "I'd like to
use Times Roman please". Then specify a character
string and have it rendered immediately at the
current point in space. This is better than having
to download a 2MB font, which on the old networks,
took a while. This worked well enough, we used to
hand-craft PostScript files, while trying examples
from the Red Book.

Rosetta has various tasks written in different languages,
and this is "Hello World" written in PostScript language.

https://rosettacode.org/wiki/Hello_world/Line_printer#PostScript

<</PageSize [595 842]>> setpagedevice  % set page size to DIN A4
/Courier findfont                      % use Courier
12 scalefont setfont                   % 12 pt
28 802 moveto                          % 1 cm from the top and left edges
(Hello world) show                     % draw the string

That example would rely on the printer having
the Courier font onboard. Modern printing tool
chains, probably would not take a chance on that,
and they would send an embedded subset of Courier along
with the print job.

    Paul

[toc] | [prev] | [next] | [standalone]

#51579

On 12/11/2018 15.21, Paul wrote:
> Carlos E. R. wrote:
>> On 11/11/2018 05.26, Paul wrote:
>>> Paulo da Silva wrote:
>>
>> ...
>>
>>> I agree it doesn't make any sense. Not on writes.
>>> It's a reading/interpreting issue.
>>>
>>> One of the reasons these capabilities existed in the first
>>> place, is some laser printers had "resident" fonts. These
>>> may have been stored on a hard drive inside the laser printer.
>>> At the time, flash (NOR) memory was too expensive to hold
>>> the fonts.
>>>
>>> You could send a specially formulated .ps print job, to send
>>> a font to the printer. I've never done it, but heard you
>>> could do such a thing at the time.
>>>
>>> Some file capabilities existed in PostScript, that might not
>>> have been there, if it wasn't for the printer requirement.
>>>
>>> Today, we send embedded fonts in documents, so a printer
>>> with resident fonts isn't as necessary. The embedded font
>>> is a subset. I have document samples here, where a font table
>>> only has one character in it, as an example of how few characters
>>> they're willing to embed when sending them with the document.
>>
>> All printers, even ribbon printers (pin matrix), have "fonts" :-)
>>
>> In some form. They need to handle fonts in order to be able to print
>> plain ascii.
>>
>> Well, maybe winprinters don't, I do not know.
>>
>> Postscript printers have more sophisticated fonts. They can be scaled
>> (vector based?) and you do not see the "dots", the quality normally
>> keeps. Similarly I think PDF printers also have some fonts, because the
>> PDF format assumes the receiver knows how to handle a small set of
>> fonts. You can try print directly (raw) a PDF without embedded fonts and
>> it should print.
>>
>> My printer handles ps and I can send it plain ps files without sending
>> fonts and they print fine.
>>
> 
> There's a couple ways to print.
> 
> The "clumsy" way, is to send a bitmap or pixmap
> image of what is to be printed. This usually takes
> a bit of bandwidth (but not by todays standards). Back
> in the day, we had some pretty bad LAN standards.

Just use the parallel printer port ;-p


> The first laser we had at work, didn't have an internal
> interpreter. It was a "dumb" printer. It had what
> is known as a "video interface". The card feeding it,
> sent a 2Mbit/sec video signal. The "image" was then
> drawn on the drum as the drum rotated. Print jobs
> sent to such a printer, consisted of bitmaps, and
> the driver on the computer sitting next to the printer,
> would send them out via the video interface.

I have not seen those.

However, on pin and ribbon printers the computer could send text, or
just one band of the image. I don't know but I think the computer
generated the entire image then sent it band by band to the printer. My,
they were slow!  It happened with Windows 3, many "text" print jobs were
done that way. Minutes per page. WordPerfect in MsDOS was much faster
with very good (for the times) results.


> Later printers, used higher level languages, like
> PostScript or PCL or whatever. The printer has
> a parser, to read the more compact representation
> of a print job, and convert to a bitmap. (One of the
> printers had a 25MHz processor, a RISC.) On some
> of those printers, the printer didn't have enough
> RAM to hold the whole sheet of paper. This
> meant that the RAM functioned as a "fraction-of-a-page
> buffer". And the parser had to stay ahead of the
> print rate, to keep the buffer full. Only rich
> companies could afford to put more RAM in the
> printer, so an entire glorious page could be
> held in RAM. Some of those first machines were
> that cheesy.
> 

Oh, I have seen the "out of memory" message on modern laser printers.
Not the huge type, but home/small office.

The last one I saw recovered automatically somehow - maybe the computer
sent the job differently. On mine I have to use another hp language
instead of ps when it errors.

> It's those processor-equipped machines, that
> might have a hard drive with fonts. It was an option.
> It also means you could make very compact print
> jobs. You could tell the interpreter "I'd like to
> use Times Roman please". Then specify a character
> string and have it rendered immediately at the
> current point in space. This is better than having
> to download a 2MB font, which on the old networks,
> took a while. This worked well enough, we used to
> hand-craft PostScript files, while trying examples
> from the Red Book.
> 
> Rosetta has various tasks written in different languages,
> and this is "Hello World" written in PostScript language.
> 
> https://rosettacode.org/wiki/Hello_world/Line_printer#PostScript
> 
> <</PageSize [595 842]>> setpagedevice  % set page size to DIN A4
> /Courier findfont                      % use Courier
> 12 scalefont setfont                   % 12 pt
> 28 802 moveto                          % 1 cm from the top and left edges
> (Hello world) show                     % draw the string
> 
> That example would rely on the printer having
> the Courier font onboard. Modern printing tool
> chains, probably would not take a chance on that,
> and they would send an embedded subset of Courier along
> with the print job.

The driver should know what fonts the printer has. There are a few all
printers should have (I never remember which), the rest are extra.

It has to know at least one font, with variations, or the printer can
not do plain text.

-- 
Cheers,
       Carlos E.R.

[toc] | [prev] | [standalone]

Back to top | Article view | alt.os.linux

csiph-web