| Summary: | general protection / segfaults when PermitOpen=none | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Portable OpenSSH | Reporter: | Christoph Anton Mitterer <calestyo> | ||||||||||
| Component: | sshd | Assignee: | Darren Tucker <dtucker> | ||||||||||
| Status: | CLOSED FIXED | ||||||||||||
| Severity: | major | CC: | djm, dtucker | ||||||||||
| Priority: | P5 | ||||||||||||
| Version: | 6.7p1 | ||||||||||||
| Hardware: | amd64 | ||||||||||||
| OS: | Linux | ||||||||||||
| See Also: | http://bugs.debian.org/778807 | ||||||||||||
| Bug Depends on: | |||||||||||||
| Bug Blocks: | 2360 | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Christoph Anton Mitterer
2015-02-20 14:49:41 AEDT
Created attachment 2550 [details]
sshd_config
Could you try running a sshd in debugging mode on a different port (i.e. "sshd -dddp 2222") and catching it in the act of crashing? Seeing where it fails would be a great help. BTW, I can't replicate this with HEAD Created attachment 2551 [details]
ssh.log
Created attachment 2552 [details]
sshd.log
(In reply to Damien Miller from comment #2) > Could you try running a sshd in debugging mode on a different port > (i.e. "sshd -dddp 2222") and catching it in the act of crashing? > Seeing where it fails would be a great help. Sure, see attached files: sshd and ssh output, from the later you see which tries failed (with which error) and which worked. Interestingly, the sshd quite *every time* after the end of the connection... is this because of -D? (In reply to Damien Miller from comment #3) > BTW, I can't replicate this with HEAD Mhh and have you tried with an older tag as well (i.e. 6.7p1?) and could replicate it there? (In reply to Christoph Anton Mitterer from comment #6) > (In reply to Damien Miller from comment #2) > > Could you try running a sshd in debugging mode on a different port > > (i.e. "sshd -dddp 2222") and catching it in the act of crashing? > > Seeing where it fails would be a great help. > Sure, see attached files: sshd and ssh output, from the later you > see which tries failed (with which error) and which worked. > > Interestingly, the sshd quite *every time* after the end of the > connection... is this because of -D? -D and -d mean different things, but yes -d means "run in debug mode once then exit". If you want to leave it up you can use this instead of -d: /path/to/sshd -De -o LogLevel=debug3 > (In reply to Damien Miller from comment #3) > > BTW, I can't replicate this with HEAD > Mhh and have you tried with an older tag as well (i.e. 6.7p1?) and > could replicate it there? Note that you are running a vendor-modified version of OpenSSH: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-3 It's not all that easy for us to know exactly what each vendor has changed. Even things like which compiler flags they use can make a difference. Have you reported this to Debian? They're in a much better position to reproduce a problem. Damien and I spent a couple of hours with a VM trying to figure this out and we now think we know what the cause is. I'll update this bug again once we're sure we are on the right track. Hey. Sorry for not having answered earlier... this got somehow hidden under a huge pile of mails the last days =) Yes I did report it in Debian, see the URL set here in the bug report's "See Also section" (http://bugs.debian.org/778807) But nothing has happened there so far. When I reported this in the beginning, I had a short glance whether any of Debian's patches obviously touches something in this area,... nothing I'd have seen (OTOH I'm not an OpenSSH code expert). It's great to hear that you possibly found the issue :-) Thanks, Chris. Created attachment 2617 [details]
calloc permitted_adm_opens instead of malloc to ensure it's zeroed
Here's the fix. I'll be commit this shortly.
The patch has been applied and will be in the 6.9 release. Thanks for the report! Set all RESOLVED bugs to CLOSED with release of OpenSSH 7.1 |