buglwIP - A Lightweight TCP/IP stack - Bugs: bug #56197, HTTPD SSI handler does not handle...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #56197: HTTPD SSI handler does not handle character sequence /< properly

Submitter:  Matthias Dietrich <mdietrich>
Submitted:  Tue 23 Apr 2019 12:06:00 PM UTC
   
 
Category:  apps Severity:  3 - Normal
Item Group:  Faulty Behaviour Status:  Duplicate
Privacy:  Public Assigned to:  goldsimon
Open/Closed:  Closed Planned Release:  None
lwIP version:  Other

Thu 30 Jan 2020 10:34:33 PM UTC, comment #4: 

I think this is a duplicate to bug #55702, which has already been fixed. Please check current master and report back here if it is not fixed.

Thanks. Closing as duplicate.

Simon Goldschmidt <goldsimon>
Group administrator
Thu 30 Jan 2020 10:26:28 PM UTC, comment #3: 


> But yes, I can provide a patch.


I don' see any :-(

Simon Goldschmidt <goldsimon>
Group administrator
Mon 06 May 2019 12:43:53 PM UTC, comment #2: 

Sure. Actually I could have sent a patch with the bug report, but the thing is, I am not using the current HEAD version in my project right now, so I was not sure how you want to proceed.
But yes, I can provide a patch.

Matthias Dietrich <mdietrich>
Mon 06 May 2019 10:26:51 AM UTC, comment #1: 

Can you provide a (tested ;-) ) patch that works on your system?

Dirk Ziegelmeier <dziegel>
Group administrator
Tue 23 Apr 2019 12:06:00 PM UTC, original submission:  

The httpd server supports two sets of SSI markers ('<!--#' and '/*#'). Unfortunately, the parsing function does not handle properly the case where a character sequence starts with characters of one marker and continues with the first character of another marker.

Example: <img src="images/<!--#PicDevice-->.png" />

When the parser hits the first '/' character, it changes its state from TAG_NONE to TAG_LEADIN, as '/' could be the start of the '/*#' marker. The parser then moves to the next character ('<'). The state machine now checks whether this character ('<') matches the '/*#' marker. As this is not the case, the state is switched back to TAG_NONE and the parser moves to the next character ('!'). Unfortunenately, we have now lost the possibility of checking whether '<' was the start of a marker.

Suggestion:
in the state "TAG_LEADIN", only move to the next character
in the stream when we have found a matching character,
otherwise just change the state back to TAG_NONE but do not
increase ssi->parsed. This allows to parse again the current character and detect the start of another marker.



Matthias Dietrich <mdietrich>

 

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

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 goldsimon (Posted a comment)
  • -email is unavailable- added by dziegel (Posted a comment)
  • -email is unavailable- added by mdietrich (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.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-01-30 goldsimon StatusNone Duplicate
        Assigned toNone goldsimon
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code