From mwlucas at michaelwlucas.com  Fri Nov 15 09:57:35 2019
From: mwlucas at michaelwlucas.com (Michael W. Lucas)
Date: Fri, 15 Nov 2019 09:57:35 -0500
Subject: [Semibug] 19 November meeting
Message-ID: <20191115145735.GA68543@mail.mwl.io>

As our usual meeting place is unavailable, we'll have an informal
meeting at Leo's. I'll bring my laptop to show some sudo slides.

A final decision on MeatBSD locale shall be made.

January, I'm talking the hellhole of SNMP.

==ml


-- 
Michael W. Lucas 	https://mwl.io/
author of: Absolute OpenBSD, SSH Mastery, git commit murder,
Immortal Clay, PGP & GPG, Absolute FreeBSD, etc, etc, etc...


From jeff at nucleus.mi.org  Fri Nov 15 10:04:38 2019
From: jeff at nucleus.mi.org (Marraccini, Jeffrey)
Date: Fri, 15 Nov 2019 10:04:38 -0500
Subject: [Semibug] 19 November meeting
In-Reply-To: <20191115145735.GA68543@mail.mwl.io>
References: <20191115145735.GA68543@mail.mwl.io>
Message-ID: <CAKhM2YtzsNi2sQvDQBjkkVWcfPjVUMX3QKgmbUwWP6CeOhoBrA@mail.gmail.com>

Thank you, Michael and all of you!  Wishing you all a very enjoyable
Thanksgiving, and please drive safe.  I will collect any notes from the
Microsoft meeting during our normal meeting time and share them in Jan.


On Fri, Nov 15, 2019 at 9:57 AM Michael W. Lucas <mwlucas at michaelwlucas.com>
wrote:

> As our usual meeting place is unavailable, we'll have an informal
> meeting at Leo's. I'll bring my laptop to show some sudo slides.
>
> A final decision on MeatBSD locale shall be made.
>
> January, I'm talking the hellhole of SNMP.
>
> ==ml
>
>
> --
> Michael W. Lucas        https://mwl.io/
> author of: Absolute OpenBSD, SSH Mastery, git commit murder,
> Immortal Clay, PGP & GPG, Absolute FreeBSD, etc, etc, etc...
>
> _______________________________________________
> Semibug mailing list
> Semibug at lists.nycbug.org
> http://lists.nycbug.org:8080/mailman/listinfo/semibug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nycbug.org:8080/pipermail/semibug/attachments/20191115/a4ed8c3d/attachment.html>

From mwlucas at michaelwlucas.com  Tue Nov 19 16:46:30 2019
From: mwlucas at michaelwlucas.com (Michael W. Lucas)
Date: Tue, 19 Nov 2019 16:46:30 -0500
Subject: [Semibug] TONIGHT
Message-ID: <20191119214630.GA33278@mail.mwl.io>

Final reminder: informal meetup at Leo's, as our meeting place is
closed. 7PM.

Finalizing plans for MeatBSD.

==ml


-- 
Michael W. Lucas 	https://mwl.io/
author of: Absolute OpenBSD, SSH Mastery, git commit murder,
Immortal Clay, PGP & GPG, Absolute FreeBSD, etc, etc, etc...


From gregczrk at gmail.com  Tue Nov 19 22:07:05 2019
From: gregczrk at gmail.com (Gregory Czerniak)
Date: Tue, 19 Nov 2019 22:07:05 -0500
Subject: [Semibug] Potential danger of strlcpy
Message-ID: <CA+xWLyL4YL-vWx_bEpyRS9Jm0TjvRO8nyu3BZ6PejVEfb0phRg@mail.gmail.com>

>From our discussion tonight: it can be dangerous to replace strncpy() calls
with strlcpy() in a kernel setting [1].  The problem is that since
strlcpy() doesn't zero out the remainder of a string buffer like strncpy(),
it can lead to inadvertent leaks of data from the kernel.  If that unzeroed
section of memory happens to contain internal kernel memory addresses, it
could be used to help defeat ASLR.

[1] https://twitter.com/grsecurity/status/1082957293489147904
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nycbug.org:8080/pipermail/semibug/attachments/20191119/710c99a4/attachment.html>

From josh at jggimi.net  Wed Nov 20 06:04:10 2019
From: josh at jggimi.net (Josh Grosse)
Date: Wed, 20 Nov 2019 06:04:10 -0500
Subject: [Semibug] MeatBSD announcement
Message-ID: <20191120110410.GA19474@fw2.jggimi.net>

The vote at last nights meeting broke the long-standing tie.  

We will be meating at 

     Black Rock Bar & Grill
     12515 Hall Rd, Utica, MI 48315

on Tuesday, December 17, 7:00pm.

I will contact the restaurant on Wednesday, December 1 to request
a reservation with a headcount.  

To add yourself and any guests to the headcount, please reply -- to
the list or to me -- prior to to December 1.  A confirmation of
receipt will be returned to you off-list.

Thank you.


From mjo at dojo.mi.org  Wed Nov 20 06:03:53 2019
From: mjo at dojo.mi.org (Mike O'Connor)
Date: Wed, 20 Nov 2019 06:03:53 -0500
Subject: [Semibug] Potential danger of strlcpy
In-Reply-To: <CA+xWLyL4YL-vWx_bEpyRS9Jm0TjvRO8nyu3BZ6PejVEfb0phRg@mail.gmail.com>
References: <CA+xWLyL4YL-vWx_bEpyRS9Jm0TjvRO8nyu3BZ6PejVEfb0phRg@mail.gmail.com>
Message-ID: <20191120110353.eo3jtwsuy7kuy3op@dojo.mi.org>

:From our discussion tonight: it can be dangerous to replace strncpy() calls
:with strlcpy() in a kernel setting [1].? The problem is that since strlcpy()
:doesn't zero out the remainder of a string buffer like strncpy(), it can lead
:to inadvertent leaks of data from the kernel.? If that unzeroed section of
:memory happens to contain internal kernel memory addresses, it could be used to
:help defeat ASLR.
:
:[1] https://twitter.com/grsecurity/status/1082957293489147904

FWIW, strlcpy doesn't zero out the remainder of the string buffer for
performance reasons.  zero-filling has a non-zero cost.  

In general, strlcpy won't really help you if you're not checking its
return value (assuming you can ascertain what to check against)

I'm amused that you're citing a Linux security guru, when strlcpy has
BSD history and is still verboten in glibc.  :)


-Mike

-- 
 Michael J. O'Connor                                          mjo at dojo.mi.org
 =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--=
"I go to school, but I never learn what I want to know."              -Calvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://lists.nycbug.org:8080/pipermail/semibug/attachments/20191120/9da5747f/attachment.bin>

From nick at holland-consulting.net  Wed Nov 20 08:24:23 2019
From: nick at holland-consulting.net (Nick Holland)
Date: Wed, 20 Nov 2019 08:24:23 -0500
Subject: [Semibug] Potential danger of strlcpy
In-Reply-To: <20191120110353.eo3jtwsuy7kuy3op@dojo.mi.org>
References: <CA+xWLyL4YL-vWx_bEpyRS9Jm0TjvRO8nyu3BZ6PejVEfb0phRg@mail.gmail.com>
 <20191120110353.eo3jtwsuy7kuy3op@dojo.mi.org>
Message-ID: <cad1e44a-b16a-f860-dcaf-c1bf3c36bd5d@holland-consulting.net>

On 2019-11-20 06:03, Mike O'Connor wrote:
> :From our discussion tonight: it can be dangerous to replace strncpy() calls
> :with strlcpy() in a kernel setting [1].? The problem is that since strlcpy()
> :doesn't zero out the remainder of a string buffer like strncpy(), it can lead
> :to inadvertent leaks of data from the kernel.? If that unzeroed section of
> :memory happens to contain internal kernel memory addresses, it could be used to
> :help defeat ASLR.
> :
> :[1] https://twitter.com/grsecurity/status/1082957293489147904

"strlcpy doesn't zero pad to the length provided, so if this is some buffer 
being copied in full to userland -> infoleak"

in response to:
"Another example of naive strlcpy use introducing a vulnerability"

> FWIW, strlcpy doesn't zero out the remainder of the string buffer for
> performance reasons.  zero-filling has a non-zero cost.  
> 
> In general, strlcpy won't really help you if you're not checking its
> return value (assuming you can ascertain what to check against)
> 
> I'm amused that you're citing a Linux security guru, when strlcpy has
> BSD history and is still verboten in glibc.  :)

The OpenBSD team has been pretty clear that strlcpy / strlcat is NOT
a *drop-in* replacement or intended for "naive" use.  It IS a different
function, it works differently.  The problem with strncat and strncpy
is that they don't behave as people expect. The point is it works more
understandably and predictably -- and thus, differently.

So ... improper strlcpy use introduces problems.  Yep. Water is still
wet, fire still hot, Michigan winter still gloomy.  No news.

Data leakage through unzeroed strings is a different problem -- one
complicated by compilers "optimizing" away writing of data where they
(supposedly) don't matter.  This lead to the OpenBSD team coming up with
the explicit_bzero function...which is in glibc now.  Assuming the compiler
won't "help" performance by removing "useless code" like zeroing data is
perhaps unexpectedly dangerous.  If you want data to go away (a good
thing), make it go away explicitly.

Nick.


From josh at jggimi.net  Mon Nov 25 12:26:41 2019
From: josh at jggimi.net (Josh Grosse)
Date: Mon, 25 Nov 2019 12:26:41 -0500
Subject: [Semibug] Reminder: MeatBSD RSVP
In-Reply-To: <20191120110410.GA19474@fw2.jggimi.net>
References: <20191120110410.GA19474@fw2.jggimi.net>
Message-ID: <20191125172641.GA17874@fw2.jggimi.net>

RSVP reminder:

On Wed, Nov 20, 2019 at 06:04:10AM -0500, Josh Grosse wrote:
> The vote at last nights meeting broke the long-standing tie.  
> 
> We will be meating at 
> 
>      Black Rock Bar & Grill
>      12515 Hall Rd, Utica, MI 48315
> 
> on Tuesday, December 17, 7:00pm.
> 
> I will contact the restaurant on Wednesday, December 1 to request
> a reservation with a headcount.  
> 
> To add yourself and any guests to the headcount, please reply -- to
> the list or to me -- prior to to December 1.  A confirmation of
> receipt will be returned to you off-list.
> 
> Thank you.