X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=MgsRdFDe43Vc/GBvN3uAJARjf3A+sFPo8un8eVwMM7AEYkLS+hwEa
	kyO16KDoMa6f26kPQG1jj/RId/k4ZrGA9BrHieupBQoA215brK0w+cKG6ZAfDtNT
	M7Wgua+LoGAlmcympLfHb/tQH4Vkd4rKVdNTzgw5HFkz2wAXcLIFxc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	 bh=8DFov1evjweSaInOKsm4kIbtegc=; b=uEN1w7PQEgWr4DR7yTS1MRaJcU+S
	tsBZMP4R0Opm7twUKnWtLDKemgaWeDcXXs6Sl7ABYK9oWv6mPx5NOW5vxcvH67mP
	HQ1J+lbhXvwOn/pxiwwIT6lZNGW+Iy9KsNU4ToVvey1kuEWyFsvgm+LTN9JtfJ4x
	rHVwo93DpRpUPUI=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2
X-HELO: calimero.vinschen.de
Date: Wed, 7 May 2014 16:57:36 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: snapshot 05/05: ssh segmentation fault within screen
Message-ID: <20140507145736.GN30918@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <5368525F DOT 2070301 AT shaddybaddah DOT name> <20140506163936 DOT GY30918 AT calimero DOT vinschen DOT de> <536920BB DOT 3080102 AT redhat DOT com> <20140506184915 DOT GA30918 AT calimero DOT vinschen DOT de> <20140507122218 DOT GF30918 AT calimero DOT vinschen DOT de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="CZb08McUREi1kVi+"
Content-Disposition: inline
In-Reply-To: <20140507122218.GF30918@calimero.vinschen.de>
User-Agent: Mutt/1.5.21 (2010-09-15)

--CZb08McUREi1kVi+
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On May  7 14:22, Corinna Vinschen wrote:
> On May  6 20:49, Corinna Vinschen wrote:
> > On May  6 11:49, Eric Blake wrote:
> > > On 05/06/2014 10:39 AM, Corinna Vinschen wrote:
> > >=20
> > > > The problem, which I totally not realized since I started implement=
ing
> > > > this stuff is, that by propagating this cache to child processes, s=
aid
> > > > child processes suffer from what the parent process does to the pas=
swd
> > > > structures in the cache.
> > > >=20
> > > > Screen seems to call getpwuid and then sets some of the pointers in=
 the
> > > > passwd structure it got from the call to NULL, apparently for some =
sort
> > > > of security, this way overwriting the cached passwd struct for the
> > >=20
> > > Bug in screen.  POSIX states:
> > >=20
> > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/getpwuid.ht=
ml
> > >=20
> > > The application shall not modify the structure to which the return va=
lue
> > > points, nor any storage areas pointed to by pointers within the
> > > structure. The returned pointer, and pointers within the structure,
> > > might be invalidated or the structure or the storage areas might be
> > > overwritten by a subsequent call to getpwent(), getpwnam(), or getpwu=
id().
> >=20
> > Oh, wow.  However, what if screen (thinks it) never calls getpwuid or
> > getpwnam again.  In that case it may do whatever it wants with the
> > pointers inside the returned passwd structure, doesn't it?  It certainly
> > doesn't have to expect sharing with another process.
> >=20
> > > > current user.  Ssh on the other hand tries to copy the passwd struc=
ture,
> > > > but it never checks for NULL pointers because, well, the passwd
> > > > structure never contains NULL pointers.
> > > >=20
> > > > This annihilates every advantage the cygheap caching has.
> > >=20
> > > Caching still sounds correct, let's fix the bug in screen instead of
> > > bloating cygwin to work around it.  Or maybe find a way to cause a SE=
GV
> > > in any process that tries to write into the pointer returned by getpw=
uid
> > > and friends, to help them realize their bug, rather than the current
> > > state of propagating the broken memory to other processes.
> >=20
> > Hmm, I'd have to allocate a full 4K page for this.  Also, ssh called
> > from screen works fine on Linux, even if the above behaviour is buggy...
> >=20
> > > Maybe you
> > > just memcpy the result out of the cache into local memory, instead of
> > > returning a pointer into the actual cygheap cache.
> >=20
> > Yes, that's what I was coming to realize, too.  I'm going to copy the
> > entire entry to local storage and return a pointer to that.
>=20
> I created a matching patch.  Please give the today's developer snapshot
> from http://cygwin.com/snapshots/ a try.

I just created another snapshot.  The former snapshot had an off
by one bug so the passwd buffer given to the application was one
byte short.  Please make sure to try the snapshot with timestamp
14:55:24 (x86) or 14:55:06 (x86_64).


Sorry,
Corinna

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

--CZb08McUREi1kVi+
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJTakngAAoJEPU2Bp2uRE+gXKIP/2bgusZWKNYTiDjeLeMuc6Dn
HLUl9JyENrKyouEDKHi0elJXTMMqNQ+3sTdbn2O6BIRNQc78k8L9sF6VaWNAhc9u
Mf8pMmiRDca87hdCpyXBGIo83A9VAaOG2YgX49ZoHPVQYEPuq40l183yh9imgKb/
bTmk0r4fg4PsYsS9iy9uKTHvdVNhU8LT+5lMiyno0ZR7Moiq84orMnjpYvtSnj3C
6Ws2EO7XuFJQSLM8HXzLUpVWqOBc5R5LgkuMx2UgPgy2kT6QIi0erzIZ54UEDGor
hFEacL53wmDjceOTtru/yzxbd6NAKZA7GrvRNrPz0LtDwJcLIuhLm4VdtuI6FcY1
q7BMzsasbGyZ3PhPIbG/tDRS4n+yXxGiY9AZeBmWZQ9MuASGGtcxINJ4jt2ci4V9
mRLF8tBQ0FIJ57loAT7ofxgDyPzQwl/clddDBwtqZod9L3gm0O8Z85+95GjWAxVq
v+4OXN7+/CLlKJCazCEkIjlE6flnwCxUTH534N64ErE0pE/LMg5q5LEqIpHz+w2a
ruvtHoYT7nm9IWE9tdToEk7zBxxbV5eLaYtakZRdjRUk8d8og7b2wW4G95VhdquJ
xkXug0yNbYhnn1XlCNUyvlfgs27qkcp5Du2As1vxdhQIXYCyONR/TzyL2xoYho+T
nxieJDg52x6Nvd7k4QPO
=znz9
-----END PGP SIGNATURE-----

--CZb08McUREi1kVi+--