Bug 327

Summary: monitor_fdpass.c: Expected 1 got 1075033556 - Privilege Separation
Product: Portable OpenSSH Reporter: DaZo <dazo>
Component: MiscellaneousAssignee: OpenSSH Bugzilla mailing list <openssh-bugs>
Status: CLOSED FIXED    
Severity: major    
Priority: P2    
Version: -current   
Hardware: ix86   
OS: Linux   
Attachments:
Description Flags
Patch to enable mm_receive_fd() to work under Linux kernel-2.0.x none

Description DaZo 2002-07-01 18:39:50 AEST 
When enabling the Privilege separation, I get this message in line 117
(monitor_fdpass.c,v 1.3 2002/06/04 23:05:49 markus Exp $)

It works ok on Linux 2.4.18 but not on 2.0.36 (Yes, I know I should upgrade)

How can I help you to sort this out?  I wasn't able to locate where 
CMSG_FIRSTHDR(...) was defined or struct cmsghdr 

dazo
Comment 1 Jim Knoble 2002-07-02 04:11:53 AEST 
Could you please check the error message again?  Is it:

  mm_receive_fd: recvmsg: expected received 1 got nnnnnnnn

or is it this:

  mm_receive_fd: expected type 1 got nnnnnnnn

?  Those are two different problems, within a few lines of each other.  The
exact text of the error message is important.
Comment 2 DaZo 2002-07-02 18:21:26 AEST 
The message I receive is: mm_receive_fd: expected type 1 got nnnnnnnn

I added a little more debuging to be shure, and I'm 100% shure that the program
failes in line 117 in the monitor_fdpass.c file.
Comment 3 Jim Knoble 2002-07-03 05:57:58 AEST 
Use the attached patch (against the openssh-SNAP-20020702 snapshot).

An explanation is in the openssh-unix-dev archives:
http://www.mindrot.org/pipermail/openssh-unix-dev/2002-June/013903.html
Comment 4 Jim Knoble 2002-07-03 05:59:29 AEST 
Created attachment 127 [details]
Patch to enable mm_receive_fd() to work under Linux kernel-2.0.x
Comment 5 David Gatwood 2002-07-03 09:21:20 AEST 
This isn't a security risk from what I can see.  It's a risk of reading a bogus 
file descriptor (or the wrong file descriptor).  If somebody can muck with 
your file descriptors enough to make this a security bug, then they're root 
already.  :-)

The fix for this, ideally, should be to detect the bogus value, report a 
warning in the system log, and continue.  If you get a valid file descriptor, 
then clearly the message is really of the type expected, or else it's 
garbage.  Either way, the worst it can do is maybe provide a really obscure 
local DOS attack....  As long as there are appropriate warnings in the 
system log about this being a kernel bug, it seems reasonable to work 
around it in this way.  Please consider adding such a workaround to the 
official tree.
Comment 6 DaZo 2002-07-03 17:46:39 AEST 
This seems to work!

Thank ya'll!

Dazo
Comment 7 Damien Miller 2004-04-14 12:24:18 AEST 
Mass change of RESOLVED bugs to CLOSED