[COFF] [TUHS] buffer overflow (Re: Happy birthday Morris worm

[COFF] [TUHS] buffer overflow (Re: Happy birthday Morris worm

[dave]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1300 bytes --]

(Narrowly diverted in time to COFF from TUHS when I saw Warren's email, so 
I hope Warner is on it.)

On Tue, 12 Nov 2019, Warner Losh wrote:

> POSIX can't even recognize that leap seconds exist :(

There's a movement afoot to abolish leap seconds because they are 
"inconvenient" or something; that will upset the astronomers and other 
people who care about the exact time.

>       All is not lost, though; use strncpy() instead of strcpy() etc. 
> 
> strncpy has two issues. First, it doesn't guarantee NUL termination. 
> Second, it always writes N bytes. It's for a fixed width data field, not 
> a variable length string whose buffer size is known. strlcpy is much 
> better, but still has some issues...

Yeah, I knew about the NUL termination (or lack of it) - I didn't think to 
mention it.  When I use it, I copy n-1 bytes and plant the NUL in there 
myself (depending on how I'm using it).

And I wasn't aware of strlcpy() - thanks.  Too many functions to keep 
track of these days....

Trivia: curious to see how Australia's "talking clock" (long gone in 
favour of NTP, alas) handled the leap second, I recorded it (it puts a gap 
before the last beep).  It can be heard (and seen!) over on 
www.horsfall.org/leapsecond.webm .

And yes, that old long-haired hippie is me...

-- Dave

[COFF] [TUHS] buffer overflow (Re: Happy birthday Morris worm

[dave]

On Wed, 13 Nov 2019, Dave Horsfall wrote:

> Trivia: curious to see how Australia's "talking clock" (long gone in favour 
> of NTP, alas) handled the leap second, I recorded it (it puts a gap before 
> the last beep).  It can be heard (and seen!) over on 
> www.horsfall.org/leapsecond.webm .

Jeeze; that didn't take long :-)  Yes, I monitor my logs...

-- Dave

[COFF] [TUHS] buffer overflow (Re: Happy birthday Morris worm

[peter]

On 2019-Nov-12 17:49:46 -0500, Arthur Krewat <krewat at kilonet.net> wrote:
>On 11/12/2019 5:41 PM, Robert Clausecker wrote:
>> Oh please no.  One of the things we've hopefully all learned from Pascal
>> is that length-prefixed strings suck because you can't perform anything
>> useful without copying the entire string.

Keep in mind that C doesn't have a "string" type.  The use of a NUL
terminated char array is purely convention.  There's nothing to stop
someone using a length-prefixed array (though there's virtually no
standard library support for that).

>> Rob Pike and friends showed
>> how to get strings and vectors right in the Go language where you have a
>> builtin slice type which is essentially a structure
>>
>>      struct slice(type) {
>>              type *data;
>>              size_t len, cap;
>>      };

That approach would have incurred a 12-byte overhead for each string or
vector on a PDP-11 - that would have been a substantial disincentive on
a memory-constrained system.

>And none of that stops some programmer from doing slice.cap=255 - or is 
>it read-only? ;)

Slices and strings are built-in types in Go.  They can be modelled as the
above structure but that is an implementation detail.  It is possible to
reduce the capacity of a slice (but not a string) but attempting to
increase it will result in a runtime exception ("panic" in Go speak).

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20191113/0564e548/attachment.sig>