Cygwin AF_UNIX emulation

Cygwin AF_UNIX emulation

[Christian Franke]

Hi Corinna,

Corinna Vinschen wrote:
> On Oct 13 07:37, Christian Franke wrote:
>>> I
>>> also added a comment to explain why we do this and a FIXME comment so we
>>> don't forget we're still looking for a more generic solution for the
>>> SO_PEERCRED exchange.
>> Definitely, at least because the current AF_LOCAL emulation has some
>> security issues.
> -v?

With the secret+cred exchange, the current implementation is IMO 
reasonably safe. The client cannot connect without access to the socket 
file.

Nasty detail: At least postfix sets the all AF_UNIX sockets to rw-rw-rw- 
and relies only on directory permissions (private: rwx------, public: 
rwx--x---) for access control. This is not effective on Cygwin. Due to 
the rw-rw-rw-, the 'secret' is world readable on Cygwin and another 
Cygwin specific patch is required :-)


After new setsockopt(sd, ., SO_PEERCRED, .), AF_UNIX sockets are 
definitely vulnerable. Any local process could "guess" the TCP port and 
connect to any emulated AF_UNIX server regardless of user account.


Two draft ideas for a new AF_UNIX emulation:

1)
Keep the current secret+cred exchange, but handle accept() and connect() 
differently:

After actual accept():

if (! recv client secret+cred)
   return abort_connection();
send(server secret+cred);
set_state(connected).


After actual connect():

send(client secret+cred);
set_state(connected_but_secret_missing)


Before actual recv() and getpeerid():

if (state == connected_but_secret_missing) {
   if (! recv server secret+cred)
     return abort_connection()
   set_state(connected)
}


Before actual send(): Do nothing special.

Secrets should be different such that knowledge of client secret (send 
unconditionally) does not expose the server secret.

In contrast to my first more 'symmetric' approach, this should support 
'client send() before server accept()'. Could not test it with postfix yet.

Unfortunately this leaves one security issue open: Client may send 
confidential data to malicious server if original server died. The 
client will recognize it too late in first receive.


2)
Don't exchange anything over TCP. Rely on a connection table in the 
socket file. Use 'bind before connect()' to avoid races.

local_bind:

bind(localhost:0);
getsockname(&server_port);

create_socket_file(path);
lock_socket_file(path) {
     socket_file.slot[0] = (server_port, my_creds);
}


local_connect:

bind(localhost:0)
getsockname(&client_port);

lock_socket_file(path) {
   server_port = socket_file.slot[0].port;
   peer_creds = socket_file.slot[0].credentials;
   i = find_free_slot();
   socket_file.slot[i] = (client_port, my_creds, timestamp);
}

return connect(localhost:serverport);


local_accept:

accept(&client_port);

lock_socket_file(path) {
   i = find_slot(client_port));
   peer_creds = socket_file.slot[i].credentials;
}


Problem: There is no real proof that the TCP peer is the actual peer 
listed in the file.


Christian

Re: Cygwin AF_UNIX emulation

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 5764 bytes --]

Hi Christian,

On Oct 16 23:34, Christian Franke wrote:
> Hi Corinna,
> 
> Corinna Vinschen wrote:
> >On Oct 13 07:37, Christian Franke wrote:
> >>>I
> >>>also added a comment to explain why we do this and a FIXME comment so we
> >>>don't forget we're still looking for a more generic solution for the
> >>>SO_PEERCRED exchange.
> >>Definitely, at least because the current AF_LOCAL emulation has some
> >>security issues.
> >-v?
> 
> With the secret+cred exchange, the current implementation is IMO reasonably
> safe. The client cannot connect without access to the socket file.
> 
> Nasty detail: At least postfix sets the all AF_UNIX sockets to rw-rw-rw- and
> relies only on directory permissions (private: rwx------, public: rwx--x---)
> for access control. This is not effective on Cygwin. Due to the rw-rw-rw-,
> the 'secret' is world readable on Cygwin and another Cygwin specific patch
> is required :-)

Yeah, thanks to Windows which enables the "Bypass Traverse checking"
privilege for everyone :(  At one point in 2005 I toyed with traverse
checking but eventually gave up in 2006 and reverted the stuff.

I'm still once in a while dreaming of how to enable traverse checking
again, in a limited fashion only affecting Cygwin processes.  Combined
with a mount flag, maybe.

But then again, if it is configurable by the user, and the user and
admin will expect this, and the default expectation will be that it's
switched off, the applications will have to adapt to bypassed traverse
checking anyway :-P

> After new setsockopt(sd, ., SO_PEERCRED, .), AF_UNIX sockets are definitely
> vulnerable. Any local process could "guess" the TCP port and connect to any
> emulated AF_UNIX server regardless of user account.
> 
> 
> Two draft ideas for a new AF_UNIX emulation:
> 
> 1)
> Keep the current secret+cred exchange, but handle accept() and connect()
> differently:
> 
> After actual accept():
> 
> if (! recv client secret+cred)
>   return abort_connection();
> send(server secret+cred);
> set_state(connected).
> 
> 
> After actual connect():
> 
> send(client secret+cred);
> set_state(connected_but_secret_missing)
> 
> 
> Before actual recv() and getpeerid():
> 
> if (state == connected_but_secret_missing) {
>   if (! recv server secret+cred)
>     return abort_connection()
>   set_state(connected)
> }
> 
> 
> Before actual send(): Do nothing special.

Yeah, both peers simply send their stuff and expect the same from
the peer, thus it's not actually a handshake but just an exchange
of information.

On the plus side, it's pretty unlikely that a non-Cygwin process is
*expecting* a Cygwin process on the other end and as such, the info
exchange is unexpected.

> Secrets should be different such that knowledge of client secret (send
> unconditionally) does not expose the server secret.

How so?  The binding server creates the file, the secret is in the file.
Only a process which knows that this socket is connected to this file's
content would know how to fetch the secret, a malicious non-Cygwin
client wouldn't know where to look for this info.

> In contrast to my first more 'symmetric' approach, this should support
> 'client send() before server accept()'. Could not test it with postfix yet.
> 
> Unfortunately this leaves one security issue open: Client may send
> confidential data to malicious server if original server died. The client
> will recognize it too late in first receive.

In theory, a malicious server could wait for the client package and
read the content, thus it knows the socket secret and send its own
package with the secret gained from the client.

> 2)
> Don't exchange anything over TCP. Rely on a connection table in the socket
> file. Use 'bind before connect()' to avoid races.
> 
> local_bind:
> 
> bind(localhost:0);
> getsockname(&server_port);
> 
> create_socket_file(path);
> lock_socket_file(path) {
>     socket_file.slot[0] = (server_port, my_creds);
> }
> 
> 
> local_connect:
> 
> bind(localhost:0)
> getsockname(&client_port);
> 
> lock_socket_file(path) {
>   server_port = socket_file.slot[0].port;
>   peer_creds = socket_file.slot[0].credentials;
>   i = find_free_slot();
>   socket_file.slot[i] = (client_port, my_creds, timestamp);
> }
> 
> return connect(localhost:serverport);
> 
> 
> local_accept:
> 
> accept(&client_port);
> 
> lock_socket_file(path) {
>   i = find_slot(client_port));
>   peer_creds = socket_file.slot[i].credentials;
> }
> 
> 
> Problem: There is no real proof that the TCP peer is the actual peer listed
> in the file.

Right.

Btw., considering my change to call the connect side of the handshake
only when an FD_CONNECT arrives, what exactly is postfix still missing?

The connect call itself doesn't hang anymore, and the FD_CONNECT
handshake is independent of the actually requested events (FD_READ,
FD_WRITE, etc).  So, right now I don't understand why postfix would
still need to switch off the handshake.

Independently of that, I'm mulling over the idea to introduce a
sidechannel via pipe.  Pipes can be used to fetch the windows PID of the
peer (GetNamedPipeClientProcessId, GetNamedPipeServerProcessId), and the
server can impersonate the client and thus fetch the user and group
information from the client's token.  The client would get the uid/gid
info back from the server via the pipe or, even more secure, via
CreateRemoteThread.

I'm still somewhat fuzzy about the details, so for now it's just
wild brainstorming...


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Cygwin AF_UNIX emulation

[Christian Franke]

Corinna Vinschen wrote:
> Hi Christian,
>
> On Oct 16 23:34, Christian Franke wrote:
>>
>> Nasty detail: At least postfix sets the all AF_UNIX sockets to rw-rw-rw- and
>> relies only on directory permissions (private: rwx------, public: rwx--x---)
>> for access control. This is not effective on Cygwin. Due to the rw-rw-rw-,
>> the 'secret' is world readable on Cygwin and another Cygwin specific patch
>> is required :-)
> Yeah, thanks to Windows which enables the "Bypass Traverse checking"
> privilege for everyone :(  At one point in 2005 I toyed with traverse
> checking but eventually gave up in 2006 and reverted the stuff.

This does not appear as an Se*Privilege in the token, correct?

Any idea why this was added for everyone?


> I'm still once in a while dreaming of how to enable traverse checking
> again, in a limited fashion only affecting Cygwin processes.  Combined
> with a mount flag, maybe.
>
> But then again, if it is configurable by the user, and the user and
> admin will expect this, and the default expectation will be that it's
> switched off, the applications will have to adapt to bypassed traverse
> checking anyway :-P
>
>> After new setsockopt(sd, ., SO_PEERCRED, .), AF_UNIX sockets are definitely
>> vulnerable. Any local process could "guess" the TCP port and connect to any
>> emulated AF_UNIX server regardless of user account.
>>
>>
>> Two draft ideas for a new AF_UNIX emulation:
>>
>> 1)
>> Keep the current secret+cred exchange, but handle accept() and connect()
>> differently:
>>
>> After actual accept():
>>
>> if (! recv client secret+cred)
>>    return abort_connection();
>> send(server secret+cred);
>> set_state(connected).
>>
>>
>> After actual connect():
>>
>> send(client secret+cred);
>> set_state(connected_but_secret_missing)
>>
>>
>> Before actual recv() and getpeerid():
>>
>> if (state == connected_but_secret_missing) {
>>    if (! recv server secret+cred)
>>      return abort_connection()
>>    set_state(connected)
>> }
>>
>>
>> Before actual send(): Do nothing special.
> Yeah, both peers simply send their stuff and expect the same from
> the peer, thus it's not actually a handshake but just an exchange
> of information.
>
> On the plus side, it's pretty unlikely that a non-Cygwin process is
> *expecting* a Cygwin process on the other end and as such, the info
> exchange is unexpected.
>
>> Secrets should be different such that knowledge of client secret (send
>> unconditionally) does not expose the server secret.
> How so?  The binding server creates the file, the secret is in the file.
> Only a process which knows that this socket is connected to this file's
> content would know how to fetch the secret, a malicious non-Cygwin
> client wouldn't know where to look for this info.
>
>> In contrast to my first more 'symmetric' approach, this should support
>> 'client send() before server accept()'. Could not test it with postfix yet.
>>
>> Unfortunately this leaves one security issue open: Client may send
>> confidential data to malicious server if original server died. The client
>> will recognize it too late in first receive.
> In theory, a malicious server could wait for the client package and
> read the content, thus it knows the socket secret and send its own
> package with the secret gained from the client.

That's exactly why the server bind() should write two independent 
secrets to the file. Receiving the secret from the client does not help 
the attacker to fake the server secret then.

The only drawback which remains is that the client performs the send() 
before first recv() unconditionally. It will realize the bad server 
secret lately on first recv().


>
>> ...
>>
>>
>> Problem: There is no real proof that the TCP peer is the actual peer listed
>> in the file.
> Right.
>
> Btw., considering my change to call the connect side of the handshake
> only when an FD_CONNECT arrives, what exactly is postfix still missing?
>
> The connect call itself doesn't hang anymore, and the FD_CONNECT
> handshake is independent of the actually requested events (FD_READ,
> FD_WRITE, etc).  So, right now I don't understand why postfix would
> still need to switch off the handshake.

With 20141014 snapshot, it hangs in poll({client_sd, POLLOUT}, 1, -1) 
after a nonblocking connect() and could not be kill()ed.

postfix master unconditionally starts up some services like qmgr and 
pickup by connecting to itself:

   bind(listen_sd, "public/pickup")
     listen(listen_sd, .);

             set_nonblocking(client_sd);
             // Cygwin 1.7.32-1 hangs here:
             connect(client_sd, "public/pickup");
             // Snapshot 20141014 hangs here:
             poll({client_sd, POLLOUT}, 1, -1)
             // My first approach hung here:
             send("some initial command");

     poll({listen_sd, POLLIN}, ., .)
     spawn("/usr/libexec/postfix/pickup");

     in child process:
     accept(listen_sd, .);


BTW: I could ITP postfix in one week or so. It would rely on the 
SO_PEERCRED workaround for now. Any objections?


> Independently of that, I'm mulling over the idea to introduce a
> sidechannel via pipe.  Pipes can be used to fetch the windows PID of the
> peer (GetNamedPipeClientProcessId, GetNamedPipeServerProcessId), and the
> server can impersonate the client and thus fetch the user and group
> information from the client's token.  The client would get the uid/gid
> info back from the server via the pipe or, even more secure, via
> CreateRemoteThread.
>
> I'm still somewhat fuzzy about the details, so for now it's just
> wild brainstorming...

Hmm... sounds promising.

Christian

Re: Cygwin AF_UNIX emulation

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 4421 bytes --]

On Oct 17 21:29, Christian Franke wrote:
> Corinna Vinschen wrote:
> >On Oct 16 23:34, Christian Franke wrote:
> >>Nasty detail: At least postfix sets the all AF_UNIX sockets to rw-rw-rw- and
> >>relies only on directory permissions (private: rwx------, public: rwx--x---)
> >>for access control. This is not effective on Cygwin. Due to the rw-rw-rw-,
> >>the 'secret' is world readable on Cygwin and another Cygwin specific patch
> >>is required :-)
> >Yeah, thanks to Windows which enables the "Bypass Traverse checking"
> >privilege for everyone :(  At one point in 2005 I toyed with traverse
> >checking but eventually gave up in 2006 and reverted the stuff.
> 
> This does not appear as an Se*Privilege in the token, correct?

It's in the token, and it's an ugly amalgamation of two unrelated
mechanisms(*):

  SE_CHANGE_NOTIFY_NAME

    Required to receive notifications of changes to files or
    directories. This privilege also causes the system to skip all
    traversal access checks. It is enabled by default for all users.

    User Right: Bypass traverse checking.

> Any idea why this was added for everyone?

It's in there and set by default since the dawn of (NT) time, probably
for the notifications to work, and as a side-effect, being faster.

> >In theory, a malicious server could wait for the client package and
> >read the content, thus it knows the socket secret and send its own
> >package with the secret gained from the client.
> 
> That's exactly why the server bind() should write two independent secrets to
> the file. Receiving the secret from the client does not help the attacker to
> fake the server secret then.
> 
> The only drawback which remains is that the client performs the send()
> before first recv() unconditionally. It will realize the bad server secret
> lately on first recv().

Yeah, but it might be better than nothing and if it avoids the hangs,
even better.

> >Btw., considering my change to call the connect side of the handshake
> >only when an FD_CONNECT arrives, what exactly is postfix still missing?
> >[...]
> 
> With 20141014 snapshot, it hangs in poll({client_sd, POLLOUT}, 1, -1) after
> a nonblocking connect() and could not be kill()ed.
> 
> postfix master unconditionally starts up some services like qmgr and pickup
> by connecting to itself:
> 
>   bind(listen_sd, "public/pickup")
>     listen(listen_sd, .);
> 
>             set_nonblocking(client_sd);
>             // Cygwin 1.7.32-1 hangs here:
>             connect(client_sd, "public/pickup");
>             // Snapshot 20141014 hangs here:
>             poll({client_sd, POLLOUT}, 1, -1)

Oh, ok.  The FD_CONNECT handling just moved the hanging to a later
call to wait_for_events.  Sigh.

> BTW: I could ITP postfix in one week or so. It would rely on the SO_PEERCRED
> workaround for now. Any objections?

Uh, we're not having a Cygwin release it could work with for now.
It might be better to wait until then, if that's ok with you.

I'm planning to release 1.7.33(**) in November at the latest.  I'm
not going to stall this release until we have another solution for
the aforementioned problems, the SO_PEERCRED wourkaround should
suffice for now.

> >Independently of that, I'm mulling over the idea to introduce a
> >sidechannel via pipe.
> 
> Hmm... sounds promising.

...and like a lot of work.  Any other, simpler idea welcome.

Btw., I'm also just looking into the WSAAccept and WSAConnect functions.
These functions provide a way to submit application controlled connect
data in a handshake-like operation, and they are supposed to work with
non-blocking sockets.  Maybe these functions would work for us?

Also, starting with Windows Vista there is a function
WSAImpersonateSocketPeer.  Yes, really.  Maybe that's a way out, which
would also leave Windows XP/2003 behind.  Given that XP is out of
support now, and given that 2K3 goes out of support next April, I'd
not be overly concerned.


Corinna

(*)  http://msdn.microsoft.com/en-us/library/windows/desktop/bb530716%28v=vs.85%29.aspx

(**) Or 1.9.0.  I'm not sure yet if we should bump the DLL major version
     due to the massive changes to user and group handling or not.

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Cygwin AF_UNIX emulation

[Christian Franke]

Corinna Vinschen wrote:
> On Oct 17 21:29, Christian Franke wrote:
>> Corinna Vinschen wrote:
>>> On Oct 16 23:34, Christian Franke wrote:
>>>> Nasty detail: At least postfix sets the all AF_UNIX sockets to rw-rw-rw- and
>>>> relies only on directory permissions (private: rwx------, public: rwx--x---)
>>>> for access control. This is not effective on Cygwin. Due to the rw-rw-rw-,
>>>> the 'secret' is world readable on Cygwin and another Cygwin specific patch
>>>> is required :-)
>>> Yeah, thanks to Windows which enables the "Bypass Traverse checking"
>>> privilege for everyone :(  At one point in 2005 I toyed with traverse
>>> checking but eventually gave up in 2006 and reverted the stuff.
>> This does not appear as an Se*Privilege in the token, correct?
> It's in the token, and it's an ugly amalgamation of two unrelated
> mechanisms(*):
>
>    SE_CHANGE_NOTIFY_NAME
>
>      Required to receive notifications of changes to files or
>      directories. This privilege also causes the system to skip all
>      traversal access checks. It is enabled by default for all users.
>
>      User Right: Bypass traverse checking.

An unexpected "feature", IMO.

Hmm.... after removing this privilege, Cygwin returns garbage stat() 
info, for any path below the 'forbidden directory':

$ uname -srvm
CYGWIN_NT-6.1-WOW64 1.7.33s(0.278/5/3) 20141017 14:39:49 i686

$ cd /var/spool/postfix/

$ ls -ld private
drwx------+ 1 postfix none 0 Oct 18 16:39 private

$ ls -l private
ls: cannot open directory private: Permission denied

$ ls -l private/smtp
srw-rw-rw- 1 postfix none 0 Oct 18 16:39 private/smtp

$ cygdrop -p ChangeNotify ls -l private/smtp
-rw-r----- 1 Unknown+User Unknown+Group 6991943424855812584 Jun 23 1909 
private/smtp

$ ls -l private/no/such/path
ls: cannot access private/no/such/path: No such file or directory

$ cygdrop -p ChangeNotify ls -l private/no/such/path
-rw-r----- 1 Unknown+User Unknown+Group 6991943424855812584 Jun 23 1909 
private/no/such/path

$ cygdrop -p ChangeNotify ls -l /tmp/no/such/path
ls: cannot access /tmp/no/such/path: No such file or directory


>> BTW: I could ITP postfix in one week or so. It would rely on the SO_PEERCRED
>> workaround for now. Any objections?
> Uh, we're not having a Cygwin release it could work with for now.
> It might be better to wait until then, if that's ok with you.

Of course.

My intention was to get the initial packing issues fixed early such that 
the actual upload could be done when a the first compatible Cygwin 
release is available.


> I'm planning to release 1.7.33(**) in November at the latest.  I'm
> not going to stall this release until we have another solution for
> the aforementioned problems, the SO_PEERCRED wourkaround should
> suffice for now.

OK.


> (**) Or 1.9.0. I'm not sure yet if we should bump the DLL major 
> version due to the massive changes to user and group handling or not. 

During testing postfix with recent snapshots, I found nothing that 
needed to be changed in my existing installations which have complete 
/etc/passwd and group files. The only visible difference is that Cygwin 
now reports groups not seen before (like 4="INTERAKTIV").

So keeping 1.7.* might be OK.

Christian

Re: Cygwin AF_UNIX emulation

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1537 bytes --]

On Oct 18 17:05, Christian Franke wrote:
> Corinna Vinschen wrote:
> >   SE_CHANGE_NOTIFY_NAME
> >
> >     Required to receive notifications of changes to files or
> >     directories. This privilege also causes the system to skip all
> >     traversal access checks. It is enabled by default for all users.
> >
> >     User Right: Bypass traverse checking.
> 
> An unexpected "feature", IMO.
> 
> Hmm.... after removing this privilege, Cygwin returns garbage stat() info,
> for any path below the 'forbidden directory':
> 
> $ uname -srvm
> CYGWIN_NT-6.1-WOW64 1.7.33s(0.278/5/3) 20141017 14:39:49 i686
> 
> $ cd /var/spool/postfix/
> 
> $ ls -ld private
> drwx------+ 1 postfix none 0 Oct 18 16:39 private
> 
> $ ls -l private
> ls: cannot open directory private: Permission denied
> 
> $ ls -l private/smtp
> srw-rw-rw- 1 postfix none 0 Oct 18 16:39 private/smtp
> 
> $ cygdrop -p ChangeNotify ls -l private/smtp
> -rw-r----- 1 Unknown+User Unknown+Group 6991943424855812584 Jun 23 1909
> private/smtp
> 
> $ ls -l private/no/such/path
> ls: cannot access private/no/such/path: No such file or directory
> 
> $ cygdrop -p ChangeNotify ls -l private/no/such/path
> -rw-r----- 1 Unknown+User Unknown+Group 6991943424855812584 Jun 23 1909
> private/no/such/path

That should work better now.  I just applied a patch to CVS.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Cygwin AF_UNIX emulation

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 925 bytes --]

On Oct 18 12:35, Corinna Vinschen wrote:
> Btw., I'm also just looking into the WSAAccept and WSAConnect functions.
> These functions provide a way to submit application controlled connect
> data in a handshake-like operation, and they are supposed to work with
> non-blocking sockets.  Maybe these functions would work for us?

No, they don't.  Sending and receiving connect data is not supported by
TCP/IP.

> Also, starting with Windows Vista there is a function
> WSAImpersonateSocketPeer.  Yes, really.  Maybe that's a way out, which
> would also leave Windows XP/2003 behind.  Given that XP is out of
> support now, and given that 2K3 goes out of support next April, I'd
> not be overly concerned.

That's still an option to think about...


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]