bugGNU troff - Bugs: bug #61424, [libgroff] directory traversal in...

 
 

bug #61424: [libgroff] directory traversal in .fp request

Submitted by:  G. Branden Robinson <gbranden>
Submitted on:  Thu 04 Nov 2021 09:09:12 AM UTC
 
Category:  Core Severity:  4 - Important
Item Group:  Incorrect behaviour Status:  Fixed
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Closed Planned Release:  1.23.0
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       No canned response available

 

( Jump to the original submission )

Wed 29 Dec 2021 07:29:52 PM UTC, comment #6: 

Weeeeeeeird.  I, too, can reproduce it -- if I'm far enough below my home directory.

With the file bogusfont in ~, a hello-dave.roff in ~/1/2/3/4 (with the appropriate number of instances of "../" in its .fp call) produces EVIL.  But in ~/1/2/3 or higher (with the path in the .fp line adjusted accordingly), it produces WORD.

Dave <barx>
Project Member
Tue 28 Dec 2021 05:50:12 AM UTC, comment #5: 

comment #4:

> The bug has been fixed, but in case someone else tries the example and is as puzzled as I was:
>
> original submission:
> > Output:
> >

> > $ nroff EXPERIMENTS/hello-dave.roff
> > EVIL

>
> I could not for the life of me get this output from groff 1.22.4 given the described setup (with paths altered to match my local system).  I was finally able to replicate it by moving ~/bogusfont into ~/devascii/bogusfont, and altering the pathname in hello-dave.roff to match.  Even though the full path is in the .fp request, I still needed a dev* directory above bogusfont, and its name had to match the current output device.  I'm mildly curious why it worked for Branden without those constraints.
>
> (Another curious constraint is that merely specifying a relative path starting with ../ was insufficient to trigger the bug; the path had to traverse all the way up to the root directory and back down for .fp to read the file.)


That is indeed odd, because I still can reproduce the
behavior shown, using the same setup, with Debian's groff 1.22.4
package (1.22.4-5, to be precise).

I can even get it to work using an absolute file name for the
input file from a far-away directory.

$ cd /tmp
$ nroff ~/src/GIT/groff/EXPERIMENTS/hello-dave.roff
EVIL
$ mv ~/bogusfont ~/src/GIT/groff/ATTIC/
$ nroff ~/src/GIT/groff/EXPERIMENTS/hello-dave.roff
WORD

As is shown above, the surprising output goes away if I move
the "bogus font" out of my home directory whence the `fp`
request is trying to load it.

Does this help at all?  One reason I characterize this defect as
"directory traversal" is that the input file causes the
formatter to read a font description file from a place that is
not in the font path.

G. Branden Robinson <gbranden>
Project Administrator
Fri 24 Dec 2021 02:34:49 AM UTC, comment #4: 

The bug has been fixed, but in case someone else tries the example and is as puzzled as I was:

original submission:

> Output:
>

> $ nroff EXPERIMENTS/hello-dave.roff
> EVIL


I could not for the life of me get this output from groff 1.22.4 given the described setup (with paths altered to match my local system).  I was finally able to replicate it by moving ~/bogusfont into ~/devascii/bogusfont, and altering the pathname in hello-dave.roff to match.  Even though the full path is in the .fp request, I still needed a dev* directory above bogusfont, and its name had to match the current output device.  I'm mildly curious why it worked for Branden without those constraints.

(Another curious constraint is that merely specifying a relative path starting with ../ was insufficient to trigger the bug; the path had to traverse all the way up to the root directory and back down for .fp to read the file.)

Dave <barx>
Project Member
Sun 07 Nov 2021 08:06:57 AM UTC, comment #3: 

commit a891161bc94c7b6a6a3572cc82f31e5029078d7b
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Sun Nov 7 10:31:02 2021 +1100

    [libgroff]: Fix Savannah #61424.

    * src/libs/libgroff/fontfile.cpp (font::open_file): Don't open
      user-specified font file names with slashes in them; i.e., don't
      traverse directories outside the configured font path.  Also refuse to
      open the file if the `sprintf()` used to construct its file name
      doesn't write the expected quantity of bytes to the destination
      buffer.

    Fixes <https://savannah.gnu.org/bugs/?61424>.  Thanks to Ingo Schwarze
    for feedback.

commit 52f396189a4a9dd1294b16c6f84fcd47e4359221
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Sun Nov 7 02:43:53 2021 +1100

    [libgroff]: Regression-test Savannah #61424.

    * src/roff/groff/tests/fp_should_not_traverse_directories.sh: Do it.
    * src/roff/groff/tests/artifacts/HONEYPOT: Add test artifact.
    * src/roff/groff/tests/artifacts/devascii/README: ...and this; we need
      an empty directory to make the test work but such things tend to look
      unintentional.

G. Branden Robinson <gbranden>
Project Administrator
Sat 06 Nov 2021 11:32:33 PM UTC, comment #2: 

Got feedback from Ingo.  Proceeding.

G. Branden Robinson <gbranden>
Project Administrator
Thu 04 Nov 2021 03:16:10 PM UTC, comment #1: 
G. Branden Robinson <gbranden>
Project Administrator
Thu 04 Nov 2021 09:09:12 AM UTC, original submission:  

Affects groff 1.22.4 and probably goes back a long way.

Setup:

$ cat ~/bogusfont
charset
W 0 0 69
O 0 0 86
R 0 0 73
D 0 0 76
$ cat EXPERIMENTS/hello-dave.roff
.\" This doesn't work...
.\".fp 5 /home/branden/bogusfont
.\" ...but this does.
.fp 5 ../../../../../../../../../../../home/branden/bogusfont
.ft 5
WORD
.pl \n(nlu

Output:

$ nroff EXPERIMENTS/hello-dave.roff
EVIL

G. Branden Robinson <gbranden>
Project Administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by barx (Posted a comment)
  • -email is unavailable- added by gbranden (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

     

     

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-11-07 gbranden StatusIn Progress => Fixed
        Open/ClosedOpen => Closed
        Planned ReleaseNone => 1.23.0
    2021-11-06 gbranden Item GroupNone => Incorrect behaviour
        StatusNeed Info => In Progress
    2021-11-04 gbranden StatusIn Progress => Need Info

    Back to the top


    Powered by Savane 3.9