| Summary: | Problem in Pattern matching | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Portable OpenSSH | Reporter: | Carlos Ramirez <andres> | ||||
| Component: | sshd | Assignee: | Assigned to nobody <unassigned-bugs> | ||||
| Status: | NEW --- | ||||||
| Severity: | security | CC: | djm | ||||
| Priority: | P5 | ||||||
| Version: | 8.4p1 | ||||||
| Hardware: | amd64 | ||||||
| OS: | Linux | ||||||
| Attachments: |
|
||||||
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? |
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