bugGNU roff - Bugs: bug #64229, [troff] I haz a DoS attack

 
 

bug #64229: [troff] I haz a DoS attack

Submitter:  G. Branden Robinson <gbranden>
Submitted:  Sun 21 May 2023 03:29:57 PM UTC
   
 
Category:  Core Severity:  4 - Important
Item Group:  Crash/Unresponsive Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 18 Aug 2023 05:27:37 AM UTC, comment #5: 

Learned today that mandoc(1) isn't susceptible to this.

Because it doesn't support diversions at all.

https://lists.gnu.org/archive/html/groff/2023-08/msg00080.html

G. Branden Robinson <gbranden>
Group administrator
Wed 24 May 2023 01:11:19 PM UTC, comment #4: 


comment #3:

> "Infinite input causes infinite execution time and consumes infinite resources" doesn't particularly surprise me.  Do other command-line utilities fare any better?  Things like "cat" and "grep" have the luxury of being able to emit output before all input has been read, but "yes abcdefghijklm | sort" seemed happy to churn the CPU as long as I'd let it.


It's not that this fails that concerns me so much as the failure mode.

In all of these cases the formatter got nuked by the kernel OOM killer.  This means an uncontrolled crash.

I don't know what other troff_s will do (perhaps nothing), but I think GNU _troff should be sensitive to diversion content reaching a vertical page location near INT_MAX in basic units and fatal() out.

G. Branden Robinson <gbranden>
Group administrator
Wed 24 May 2023 01:00:22 AM UTC, comment #3: 

"Infinite input causes infinite execution time and consumes infinite resources" doesn't particularly surprise me.  Do other command-line utilities fare any better?  Things like "cat" and "grep" have the luxury of being able to emit output before all input has been read, but "yes abcdefghijklm | sort" seemed happy to churn the CPU as long as I'd let it.

Dave <barx>
Group Member
Mon 22 May 2023 08:01:43 PM UTC, comment #2: 

I'm impressed with how badly Heirloom handled that.


$ time { printf '.di foo\n.nf\n'; yes abcdefghijklm; } | ./bin/nroff
Killed

real    1519m49.629s
user    1518m54.699s
sys     0m40.179s


G. Branden Robinson <gbranden>
Group administrator
Sun 21 May 2023 10:21:36 PM UTC, comment #1: 

Over 7 hours later, RSS now 8.4 GB and growing, and Heirloom still hasn't been killed.

I guess a slow algorithm is one defense against attack, like rate-limiting login attempts...

G. Branden Robinson <gbranden>
Group administrator
Sun 21 May 2023 03:29:57 PM UTC, original submission:  

Affects groff 1.22.4.  Maybe every groff ever.

Also Heirloom Doctools nroff.[1]

Also DWB 3.3 nroff.

Maybe every *roff ever...


$ { printf '.di foo\n.nf\n'; yes abcdefghijklm; } | nroff
groff: troff: Signal 9


[1] Well, I think so...its resident set size is at 1.7 GB and growing without apparent bound but it is way slower at it than groff (27 seconds) or DWB (1 minute 32 seconds), which got killed by the kernel after a couple of minutes.  Heirloom is still grinding after 20 minutes.  So they may have a whole 'nother problem besides this one.

G. Branden Robinson <gbranden>
Group 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.

     

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-58d6.
    Corresponding source code