Bug 3255 - Problem in Pattern matching
Summary: Problem in Pattern matching
Status: NEW
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: sshd (show other bugs)
Version: 8.4p1
Hardware: amd64 Linux
: P5 security
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-01-25 05:08 AEDT by Carlos Ramirez
Modified: 2021-01-25 10:41 AEDT (History)
1 user (show)

See Also:


Attachments
PoC - triggers infinite loop in match_pattern() (41 bytes, application/octet-stream)
2021-01-25 05:08 AEDT, Carlos Ramirez
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Carlos Ramirez 2021-01-25 05:08:16 AEDT
Created attachment 3467 [details]
PoC - triggers infinite loop in match_pattern()

I have just uncovered a problem that seems to occur in match_pattern(), a malcrafted input can send the function into an infinite loop.

NOTE: As match_pattern() is invoked from auth.c [allowed_user() -> ga_match() -> match_pattern() ] for authentication checks, there could be a security impact under a some contexts, this needs to be investigated. Just in case, I am opening the issue as private.

This affects both, the server (sshd) and the client (ssh - if you load a config file).

Impact
- Availability of server/client application
- There could be impact on confidentiality - call flow from from auth.c to ga_match() -> ga_match() -> match_pattern() has to be investigated.

I am attaching a test scenario in which client/server get stock in match_pattern() loop when attempting to load a malcrafted config file. Filename: "infinite-loop.conf"

Quick Testing: 

SERVER
/usr/sbin/sshd -f infinite-loop.conf

CLIENT
ssh -F infinite-loop.conf localhost
Comment 1 Damien Miller 2021-01-25 10:41:41 AEDT
This was mitigated last year in commit 05bcd0cadf160fd4 and should be in the next release. It is still possible to make matching misbehave using combinations of '*' and '?'.

How do you figure this has a confidentiality impact?