linux-kernel - RE: deprecated.rst: deprecated strcpy ? (was: [PATCH] checkpatch: add a new check for strcpy/strlcpy uses)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <05733c9670a14463bec36b2cf0eeeede@AcuMS.aculab.com>
Date:   Fri, 8 Jan 2021 10:05:52 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Joe Perches' <joe@...ches.com>, Kees Cook <keescook@...omium.org>
CC:     Dwaipayan Ray <dwaipayanray1@...il.com>,
        Jonathan Corbet <corbet@....net>,
        "linux-kernel-mentees@...ts.linuxfoundation.org" 
        <linux-kernel-mentees@...ts.linuxfoundation.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Lukas Bulwahn <lukas.bulwahn@...il.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: RE: deprecated.rst: deprecated strcpy ? (was: [PATCH] checkpatch: add
 a new check for strcpy/strlcpy uses)

From: Joe Perches
> Sent: 08 January 2021 00:52
...
> > The original goal was to use another helper that worked on static
> > strings like this. Linus rejected that idea, so we're in a weird place.
> > I think we could perhaps build a strcpy() replacement that requires
> > compile-time validated arguments, and to break the build if not.
> >
> > i.e.
> >
> > given:
> > 	char array[8];
> > 	char *ptr;
> >
> > allow:
> >
> >
> > 	strcpy(array, "1234567");
> >
> > disallow:
> >
> > 	strcpy(array, "12345678");	/* too long */
> > 	strcpy(array, src);		/* not optimized, so use strscpy? */
> > 	strcpy(ptr, "1234567");		/* unknown destination size */
> > 	strcpy(ptr, src);		/* unknown destination size */
> 
> I think that's not a good idea as it's not a generic equivalent of the
> string.h code.
> 
> I still like the stracpy variant I proposed:
> 
> https://lore.kernel.org/lkml/24bb53c57767c1c2a8f266c305a670f7@sk2.org/T/#m0627aa770a076af1937cb5c610ed
> 71dab3f1da72
> https://lore.kernel.org/lkml/CAHk-=wgqQKoAnhmhGE-2PBFt7oQs9LLAATKbYa573UO=DPBE0Q@mail.gmail.com/
> 
> Linus liked a variant he called copy_string:
> 
> https://lore.kernel.org/lkml/CAHk-=wg8vLmmwTGhXM51NpSWJW8RFEAKoXxG0Hu_Q9Uwbjj8kw@mail.gmail.com/
> 
> I think the cocci scripts that convert:
> 
> 	strlcpy -> strscpy (only when return value unused)
> 	str<sln>cpy(array, "string") -> stracpy(foo, "string")
> 	s[cn]printf -> sysfs_emit
> 
> would leave relatively few uses of strcpy and sprintf variants and would
> make it much easier to analyze the remainder uses for potential overflows.

The advantage of allowing strcpy() but only when the when it can be
converted into a non-overflowing memcpy() is that you know that the
copies never get truncated.

The next round of string copy errors could easily by the 'silent truncation'
ones - so using such a strcpy() will cut down the next audit.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)