From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Hutchings Subject: Re: Report Double Fetch Bug Found in Linux-4.6.1/kernel/auditsc.c Date: Tue, 21 Jun 2016 19:20:33 +0100 Message-ID: <1466533233.27155.193.camel@decadent.org.uk> References: <20160620182215.GC25615@madcap2.tricolour.ca> <20160620191814.GA2942@redhat.com> <480FAE99-E4E1-42D0-ABD5-8DC24A7EC9BB@gmail.com> <1466502671.27155.185.camel@decadent.org.uk> <20160621181431.GD25615@madcap2.tricolour.ca> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6715343639366772184==" Return-path: In-Reply-To: <20160621181431.GD25615@madcap2.tricolour.ca> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Richard Guy Briggs Cc: security@kernel.org, Pengfei Wang , "Krinke, Jens" , Oleg Nesterov , linux-audit@redhat.com List-Id: linux-audit@redhat.com --===============6715343639366772184== Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-cIPdVwe8L0Jxs78qVRvR" --=-cIPdVwe8L0Jxs78qVRvR Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2016-06-21 at 14:14 -0400, Richard Guy Briggs wrote: > On 2016-06-21 10:51, Ben Hutchings wrote: > > On Tue, 2016-06-21 at 10:37 +0100, Pengfei Wang wrote: > > > >=20 > > > > =E5=9C=A8 2016=E5=B9=B46=E6=9C=8820=E6=97=A5=EF=BC=8C=E4=B8=8B=E5= =8D=888:18=EF=BC=8COleg Nesterov =E5=86=99=E9=81=93=EF=BC= =9A > > > >=20 > > > > Not that I understand this report, but > > > >=20 > > > > On 06/20, Richard Guy Briggs wrote: > > > > >=20 > > > > > This function is only ever called by __audit_free(), which is onl= y ever > > > > > called on failure of task creation or on exit of the task, so in = neither > > > > > case can anything else change it. > > > >=20 > > > > How so? > > > >=20 > > > > Another thread or CLONE_VM task or /proc/pid/mem can change the use= r-space > > > > memory in parallel. > > > >=20 > > > > Oleg. > > >=20 > > >=20 > > > Exactly, by saying =E2=80=9Cchange the data=E2=80=9D, I mean the modi= fication from > > > malicious users with crafted operations on the user space memory > > > directly, rather than the normal operations within the audit > > > subsystem in Linux. Moreover, since the copy operations from the user > > > space are not protected by any locks or synchronization primitives, > > > changing the data under race condition is feasible I think. Besides, > > > there isn=E2=80=99t any visible checking step in the code to guarante= e the > > > consistency between the two copy operations. > > >=20 > > > Here I would like=C2=A0to figure out what the consequences really are= once > > > the data is changed between the two copy operations, such as changing > > > a none-control string to a control string but process it as a none- > > > control string that has no control chars. I think problems will > > > happen. > >=20 > > So far as userland can see, kernel log lines are separated by newlines. >=20 > Newlines are control characters that would be caught by that filter. > That filter catches '"', < 0x21, > 0x7e. >=20 > > If we fail to escape a newline, that makes it possible to inject > > arbitrary log lines into the kernel log, which may be misleading to the > > administrator or to software parsing the log. >=20 > So, this is addressed, but I'm still trying to assess the danger of this > repeated call to copy_from_user(). The problem is that newlines can be added to the strings by another task between the first pass that checks for control characters and the second pass that copies them to the log. Ben. --=20 Ben Hutchings [W]e found...that it wasn't as easy to get programs right as we had thought. ... I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs. - Maurice Wilkes, 1949 --=-cIPdVwe8L0Jxs78qVRvR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJXaYVxAAoJEOe/yOyVhhEJqO4QAMq5X6jWJjiU+XPzTnFMVdvV sYn+sR/Ke8/dANLQ+FUTzovivVVlf/IfP/8lH9QR5gVc4PPqNw0GY5cyL7F3fT7U e3zDLriWDYw9MCgYMD2XHwHKAgzylZKsNQtV09v3rCVKBODbpq4+joexk0z6gp0p +YsZS3kZ27IJdiKCVUQrrRzD/6KvShmc2yOg3/6A5YUkoQ3pO6LtNAovDZrS7Ff/ VzjNgy06d74wtxPQ0nfOpgGxea7b1ZuraHedqxat8axB95OW1jYAlJY6t2uQ3yy6 HClAiYjG9eqYoeDDt5k1Hj9rqgGhcsnfATlq2KPCP2Sf9VMNIhyQFNB3Dj8A/RAY J8Vctg80C+27CaYetZJ5CS59xdhX1nLAwvrWiXNxVK/hmJ/tcma44yU3UFxpWFCJ HWk2MR0syrFy6xmT3aqy/2WxoCbwSafRCq0Ylp9DPynF4zsxrkUrODhVhO1dvVVl r3O8TMENjzPMGxmcfU/7bHOouKhpWcsQb92PgPOvjuRdOI5mHb2uDwjkca9Ygw5r RAWmS5SYyNKzNHkNSC5dPfOh9slNE0gWN4krzDM9B3X8i2PZtM8mTWHWmlDfoOt5 lPqz2icHcNfykqkpsrAcjWsYWC1NKQ6XTXp27Xi8tPHgocOEwOvveLOV8gijEgWR h1CbRefmEkgS+KG9svom =B2wi -----END PGP SIGNATURE----- --=-cIPdVwe8L0Jxs78qVRvR-- --===============6715343639366772184== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============6715343639366772184==--