bin/47615: security problem with ypserv

[Wolfgang.Stukenbrock%nagler-company.com@localhost]

>Number:         47615
>Category:       bin
>Synopsis:       security problem with ypserv
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Mar 04 11:35:00 +0000 2013
>Originator:     Dr. W. Stukenbrock
>Release:        NetBSD 5.1.2
>Organization:
Dr. Nagler & Company GmbH
>Environment:
        
        
System: NetBSD test-s0 5.1.2 NetBSD 5.1.2 (NSW-WS) #3: Fri Dec 21 15:15:43 CET 
2012 wgstuken@test-s0:/usr/src/sys/arch/amd64/compile/NSW-WS amd64
Architecture: x86_64
Machine: amd64
>Description:
        If a request is denied by ypserv, it sends the data of a previously 
successfull request
        processed with the error message to the client.
        This may be used to exploid the crypted passwords from the master
        password yp-map by asking the server for "something" and try to
        analyse the data send back after the error indication.
>How-To-Repeat:
        The following parts seen in ktruss of my application will demonstrate 
the problem:
        I haven't fully analysed the problem - no time at the moment, but it 
looks like the 
        "garbage" information send ist not nessesary the one of the last 
successfull call to ypserv.

        parent process: does a yp_match() for NU_HTTPS in netgroup.byname
 24147      1 httpd    sendto(0xf, 0xba6da338, 0x4c, 0, 0xba6d8008, 0x10) = 76
       
"\M-J@\M-{\M^^\0\0\0\0\0\0\0\^B\0\^A\M^F\M-$\0\0\0\^B\0\0\0\^C\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\^FWST+AG\0\0\0\0\0\bnetgroup\0\0\0\bNU_HTTPS"
 24147      1 httpd    pollts(0xba6d80d0, 0x1, 0xbfbfe8c0, 0xbfbfe8a0) = 1
 24147      1 httpd    recvfrom(0xf, 0xba6d80d8, 0x2260, 0, 0, 0) = 48
       
"\M-J@\M-{\M^^\0\0\0\^A\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\^A\0\0\0\r(-,wgstuken,)\0\0\0"

         parent process: does a call to function 11 (get yp-maps as done in 
ypwhich)
 24147      1 httpd    sendto(0xf, 0xba6da338, 0x34, 0, 0xba6d8008, 0x10) = 52
       
"\M^Fo\^F?\0\0\0\0\0\0\0\^B\0\^A\M^F\M-$\0\0\0\^B\0\0\0\v\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\^FWST+AG\0\0"
 24147      1 httpd    pollts(0xba6d80d0, 0x1, 0xbfbfe920, 0xbfbfe900) = 1
 24147      1 httpd    recvfrom(0xf, 0xba6d80d8, 0x2260, 0, 0, 0) = 864
       
"\M^Fo\^F?\0\0\0\^A\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\^A\0\0\0\^A\0\0\0\^Onetmasks.byaddr\0\0\0\0\^A\0\0\0\ano_mail\0\0\0\0\^A\0\0\0\^Ppublickey.byname\0\0\0\^A\0\0\0\^Tp"

        parent process: start child and do exec (found master_passwd.byname and 
is not UID == 0)
 24147      1 httpd    fork()                      = 9916
  9916      1 NC_auth_NIS_help emul(netbsd)
  9916      1 NC_auth_NIS_help execve("/etc/pkg/sbin/NC_auth_NIS_helper", 
0xbfbfe974, 0xbfbfee24) JUSTRETURN

        child process: does the yp-maps check again
  9916      1 NC_auth_NIS_help sendto(0x3, 0xbb92a338, 0x34, 0, 0xbb928008, 
0x10) = 52
       
"\M-tYy\M-w\0\0\0\0\0\0\0\^B\0\^A\M^F\M-$\0\0\0\^B\0\0\0\v\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\^FWST+AG\0\0"
  9916      1 NC_auth_NIS_help pollts(0xbb9280d0, 0x1, 0xbfbfecd0, 0xbfbfecb0) 
= 1
  9916      1 NC_auth_NIS_help recvfrom(0x3, 0xbb9280d8, 0x2260, 0, 0, 0) = 864
       
"\M-tYy\M-w\0\0\0\^A\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\^A\0\0\0\^A\0\0\0\^Onetmasks.byaddr\0\0\0\0\^A\0\0\0\ano_mail\0\0\0\0\^A\0\0\0\^Ppublickey.byname\0\0\0\^A\0\0\0\^T"

        child process: tries to get the password (fails, because I've missed to 
set the UID-s-bit on the binary)
  9916      1 NC_auth_NIS_help sendto(0x3, 0xbb92a338, 0x58, 0, 0xbb928008, 
0x10) = 88
       
"\M-_\M-3\^W\M-C\0\0\0\0\0\0\0\^B\0\^A\M^F\M-$\0\0\0\^B\0\0\0\^C\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\^FWST+AG\0\0\0\0\0\^Tmaster.passwd.byname\0\0\0\bwgstuken"
  9916      1 NC_auth_NIS_help pollts(0xbb9280d0, 0x1, 0xbfbfec50, 0xbfbfec30) 
= 1
  9916      1 NC_auth_NIS_help recvfrom(0x3, 0xbb9280d8, 0x2260, 0, 0, 0) = 48
       
"\M-_\M-3\^W\M-C\0\0\0\^A\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\M^?\M^?\M^?\M-z\0\0\0\r(-,wgstuken,)\0\0\0"

        Here we have the answer of the yp_match(NU_HTTPS in netgroup.byname) 
again.
        No other map has this entry - and "(-,wgstuken,)" is the only contents 
of NU_HTTPS.
        This call is done only by the parent process prior the exec call.
        I'm shure that no other process has requested NU_HTTPS from any system 
in the middle.

        The problem may be related to a cache in ypserv that tries to avoid to 
do the work again if UPD packest
        of the answer are lost and the request is submittet again.
        Perhaps the request is not checked correctly in ypserv when 
retransmitting the data.

        This behaviour of ypserv is reproducable. I've already seen some other 
data in failed requests, but
        I've no trace of that available anymore.
>Fix:
        Do not send any data back to client that does not belong to the current
        request. (I've no time to look into ypserv at the moment - sorry.)

>Unformatted: