Re: [DNG] Nasty Linux systemd security bug revealed

[aitor]

Hi Alessandro,

On 15/8/21 18:08, Alessandro Vesely via Dng wrote:

I guess we all ended up developing something similar. My take:
http://www.tana.it/svn/zdkimfilter/trunk/src/cstring.h
http://www.tana.it/svn/zdkimfilter/trunk/src/cstring.c

It's harsh as it assumes the caller _always_ checks return code.  The 
functions don't check for NULL on entry (albeit they often assert() 
it, a passage usually not compiled in production code.)  Non-nullness 
has to be checked by the caller, for example (from zaggregate.c in the 
same package):


    if (to_header)
    {
    to_header = cstr_printf(to_header, "%s %s",
    n_addr == 0? "To:": ",", dom->addr[i].addr);
    if (to_header && dom->addr[i].limit != UINT64_MAX)
    to_header = cstr_printf(to_header, " (limit=%" PRIu64 ")",
    dom->addr[i].limit);
    ++n_addr;
    }



Thanks for the link. I'll give it a try.

Cheers,

Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Alessandro Vesely via Dng]

On Thu 12/Aug/2021 13:12:29 +0200 Aitor wrote:

On 31/7/21 11:20, aitor wrote:


Sometimes I use the following buffer struct for dynamic allocation:

https://gitea.devuan.dev/aitor_czr/libnetaid/src/branch/master/backend_src/sbuf.c 



I guess we all ended up developing something similar.  My take:
http://www.tana.it/svn/zdkimfilter/trunk/src/cstring.h
http://www.tana.it/svn/zdkimfilter/trunk/src/cstring.c

It's harsh as it assumes the caller _always_ checks return code.  The functions 
don't check for NULL on entry (albeit they often assert() it, a passage usually 
not compiled in production code.)  Non-nullness has to be checked by the 
caller, for example (from zaggregate.c in the same package):

if (to_header)
{
to_header = cstr_printf(to_header, "%s %s",
n_addr == 0? "To:": ",", dom->addr[i].addr);
if (to_header && dom->addr[i].limit != UINT64_MAX)
to_header = cstr_printf(to_header, " (limit=%" PRIu64 ")",
dom->addr[i].limit);
++n_addr;
}


Best
Ale
--










___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Steve Litt]

aitor said on Thu, 12 Aug 2021 13:41:44 +0200

>On 12/8/21 13:12, aitor wrote:
>>     struct sbuf s  __cleanbuf__(free_buf);  
>I rectify:
>
>struct sbuf s  __cleanbuf__;
>
>being:
>
>#define __cleanbuf__ __attribute__((cleanup(free_buf)))

I see the attraction, Aitor, but doing this has some downsides:

1) GCC only. Everything going into the Void distro must be MUSL also,
   so the question is whether MUSL can accommodate it.

2) You'd better do *a lot* of commenting to explain that, because
   nobody learned about it in K&R. In your comments I'd have pointers
   to other resources like
   http://unixwiz.net/techtips/gnu-c-attributes.html as well as
   something you author yourself.

So the question becomes whether this barrier to forgetting to free() is
worth those downsides, which complicate your code and get the
programmer in the habit of NOT free()ing when needed.

SteveT

Steve Litt 
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[aitor]

On 12/8/21 13:12, aitor wrote:

    struct sbuf s  __cleanbuf__(free_buf);

I rectify:

struct sbuf s  __cleanbuf__;

being:

#define __cleanbuf__ __attribute__((cleanup(free_buf)))



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[aitor]

Hi,

On 31/7/21 11:20, aitor wrote:

On 31/7/21 3:02, Bruce Perens via Dng wrote:
If you want this, it's easy enough to allocate your own stack, and 
write functions that allocate from it and release the allocation.


Sometimes I use the following buffer struct for dynamic allocation:

https://gitea.devuan.dev/aitor_czr/libnetaid/src/branch/master/backend_src/sbuf.c 



A tiny version of the one developed by Johan Malm (bunsenlabs):

https://github.com/johanmalm/jgmenu/blob/master/src/sbuf.c 



I added a variadic function enabling the concatenation of several strings:

sbuf_concat(&buffer, N, string1, string2, ..., stringN);

I added a new feature to the sbuf struct using the *cleanup* common 
variable attribute [*] which runs automatically the function:


void free_buf(struct sbuf *s)
{
    free(s->buf);
}

when the variable goes out of the scope.

You can test this behavior (the complete example is here: 
https://www.gnuinos.org/sbuf/ ) running 
the following program:


#include 
#include "sbuf.h"

int main(int argc, char **argv)
{
    struct sbuf s  __cleanbuf__(free_buf);
    sbuf_init(&s);
    sbuf_addstr(&s, "oo");

    return 0;
}

When the memory is deallocated, the program will print:

Cleaning up->"oo"

Cheers,

Aitor.

[*] 
https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#Common-Variable-Attributes 






___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[al3xu5]

Hi 


Thu, 29 Jul 2021 16:57:44 -0400 - Steve Litt :

> al3xu5 said on Thu, 29 Jul 2021 17:33:10 +0200
> >
> >9) Write code to debug and log   
> 
> I'm not sure what you mean here. Do you mean to write errors and
> warnings to log files, or do you mean something more.


Both.

I do definitely mean that the code should allow debugging (better if at
different levels of depth) during execution, even with a log system. But
this is (should) be the norm of any programming.

More, I mean that debugging / log should cover not only errors and
warning, but be extended to the values of variables, calls etc. -- in
general, that is, debug / log should be related to everything that can
help a better development of the code avoiding (even potentially)
bugs and inconsistencies.

Obviously what all this means in practice depends a lot on the programming
language, and if a development framework is used or not. 

( Incidentally, I believe this can be an example of how to evaluate the
capacity of a programmer: to be capable - based on the programming
language, the eventual framework, the complexity of the project etc. -
to find the most appropriate debug / log level, and consequently choosing
the most appropriate debug / log implementation. )


Regards
al3xu5

-- 
Say NO to copyright, patents, trademarks and industrial design
restrictions!


Public GPG/PGP key: 8FC2 3121 2803 86E9 F7D8  B624 DA50 835B 2624 A36B


pgpYB_SCGtAE3.pgp
Description: Firma digitale OpenPGP
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Didier Kryn]

Le 30/07/2021 à 15:24, Enrico Weigelt, metux IT consult a écrit :
> On 21.07.21 14:36, Didier Kryn wrote:
>
>>  I want to add to the comments that this alloca() function has been
>> added (by gcc ?) to work around a missing feature of the C language:
>> dynamic allocation on the stack. 
>
> What you *actually* want is not "on stack" (directly), but automatically
> freed when leaving the function scope - doing it by moving SP is just an
> specific implementation. But actually a problematic one that needs great
> caution: you usually don't know how much free stack you actually have.


    The principle of stack allocation, when possible is a very efficient
use of the memory and cpu: it is fast and requires no calculation. This
stack is not necessarily "the stack of automatic variables"; any array
can be managed as a stack by a custom allocator. This one, as you say is
convenient because automatically reclaimed on return.

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[aitor]

Hi,

On 31/7/21 3:02, Bruce Perens via Dng wrote:
If you want this, it's easy enough to allocate your own stack, and 
write functions that allocate from it and release the allocation.


Sometimes I use the following buffer struct for dynamic allocation:

https://gitea.devuan.dev/aitor_czr/libnetaid/src/branch/master/backend_src/sbuf.c 



A tiny version of the one developed by Johan Malm (bunsenlabs):

https://github.com/johanmalm/jgmenu/blob/master/src/sbuf.c 



I added a variadic function enabling the concatenation of several strings:

sbuf_concat(&buffer, N, string1, string2, ..., stringN);

Cheers,

Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Bruce Perens via Dng]

If you want this, it's easy enough to allocate your own stack, and write
functions that allocate from it and release the allocation. If you were
writing in C++, you could make releasing the allocation automatic.

I think this illustrates why the kernel developers are taking Rust
seriously.

On Fri, Jul 30, 2021, 4:48 PM Steve Litt  wrote:

> Enrico Weigelt, metux IT consult said on Fri, 30 Jul 2021 15:24:07 +0200
>
>
> >In kernel space, we have the golden rule of not doing any larger stack
> >allocations, even not larger fixed sized arrays.
>
> Larger than how much? Surely
>
> bestdistro[12]; strncpy(bestdistro, "Devuan", strlen("Devuan"));
>
> would be OK, right?
>
> SteveT
>
> Steve Litt
> Spring 2021 featured book: Troubleshooting Techniques of the Successful
> Technologist http://www.troubleshooters.com/techniques
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Steve Litt]

Enrico Weigelt, metux IT consult said on Fri, 30 Jul 2021 15:24:07 +0200


>In kernel space, we have the golden rule of not doing any larger stack
>allocations, even not larger fixed sized arrays.

Larger than how much? Surely

bestdistro[12]; strncpy(bestdistro, "Devuan", strlen("Devuan"));

would be OK, right?

SteveT

Steve Litt 
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Enrico Weigelt, metux IT consult]

On 21.07.21 14:36, Didier Kryn wrote:


     I want to add to the comments that this alloca() function has been
added (by gcc ?) to work around a missing feature of the C language:
dynamic allocation on the stack. 


What you *actually* want is not "on stack" (directly), but automatically
freed when leaving the function scope - doing it by moving SP is just an
specific implementation. But actually a problematic one that needs great
caution: you usually don't know how much free stack you actually have.

In kernel space, we have the golden rule of not doing any larger stack
allocations, even not larger fixed sized arrays.


--mtx

--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Arnt Karlsen]

On Thu, 29 Jul 2021 20:10:24 -0400, Hendrik wrote in message 
<20210730001024.rjm4r3fxejkxe...@topoi.pooq.com>:

> On Thu, Jul 29, 2021 at 04:57:44PM -0400, Steve Litt wrote:
> > al3xu5 said on Thu, 29 Jul 2021 17:33:10 +0200  
> > >
> > >11) Document and document and document all the code (vars,
> > >functions, errors etc. ... all)  
> > 
> > I do that: Nobody else does. It really makes things difficult when I
> > need to work on or with somebody's code.  
> 
> I ofter predocument -- explain what my code is intended to do before I
>  write it. 
> 
> This is a planning document.

...and what a lot of bug hunters would wanna have handy to answer the 
"What the F*** were they even trying to do here???" debugging things.

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Steve Litt]

Hendrik Boom said on Thu, 29 Jul 2021 20:10:24 -0400

>On Thu, Jul 29, 2021 at 04:57:44PM -0400, Steve Litt wrote:
>> al3xu5 said on Thu, 29 Jul 2021 17:33:10 +0200  
>> >
>> >11) Document and document and document all the code (vars,
>> >functions, errors etc. ... all)  
>> 
>> I do that: Nobody else does. It really makes things difficult when I
>> need to work on or with somebody's code.  
>
>I ofter predocument -- explain what my code is intended to do before I
> write it. 
>
>This is a planning document.

Nice

SteveT

Steve Litt 
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Hendrik Boom]

On Thu, Jul 29, 2021 at 04:57:44PM -0400, Steve Litt wrote:
> al3xu5 said on Thu, 29 Jul 2021 17:33:10 +0200
> >
> >11) Document and document and document all the code (vars, functions,
> >errors etc. ... all)
> 
> I do that: Nobody else does. It really makes things difficult when I
> need to work on or with somebody's code.

I ofter predocument -- explain what my code is intended to do before I
 write it. 

This is a planning document.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Steve Litt]

al3xu5 said on Thu, 29 Jul 2021 17:33:10 +0200


>
>9) Write code to debug and log 

I'm not sure what you mean here. Do you mean to write errors and
warnings to log files, or do you mean something more.

>
>10) Handle all kind of errors

I know that's the *right* thing to do, and I do it often, but sometimes
I skip it because of all the typing, especially with try/except type
stuff.

I've seen, and written code with warning and error routines that
automatically write the date, give whatever text is in the argument,
and exit if necessary. THAT would make full error handling a lot easier.


>
>11) Document and document and document all the code (vars, functions,
>errors etc. ... all)

I do that: Nobody else does. It really makes things difficult when I
need to work on or with somebody's code.

>
>12) Write and run accurate tests for each routine and the whole code

Yes!

>
>13) Clearly specify the license(s) for each piece of code

Yes!


SteveT

Steve Litt 
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Steve Litt]

tempforever said on Thu, 29 Jul 2021 12:13:51 -0400

>Is this commandment (the code of one subroutine fitting into one
>screen) an absolute rule?  What about, for example, assembly-language
>programming?  Must I buy a bigger screen? :-)
>I will admit that I do very little assembly anymore, so this wouldn't
>affect me much now.  I have many routines in C that take up many lines
>(more than a screen).  

I think the point is that if you have more that a screenful of code,
you should call one or more obviously named subroutines to do some of
it. You can even to this in assembly with Jump To Subroutine and Return
From Subroutine.

SteveT

Steve Litt 
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Dr. Nikolaus Klepp]

Anno domini 2021 Thu, 29 Jul 10:57:50 -0700
 spiralofh...@spiralofhope.com scripsit:
> On Thu, 29 Jul 2021 17:33:10 +0200
> al3xu5  wrote:
> 
> > 11) Document and document and document all the code (vars, functions,
> > errors etc. ... all)
> 
> It was mentioned earlier; variables and functions wouldn't need much
> (if any) documentation if they were long and descriptive.

Oh my, the infamouse agile tantra. Real world examples: 
"this_is_the_variable_I_use_to_count_from_0_to_100" or 
"get_milliseconds_from_timestamp()".
 
> I like using short phrases, and sometimes I use poor grammar because it
> supports consistency between similar items.

Lucky you, poor grammar is at least the same language. Most programmers in this 
part of the world use their mother tonge ("german" ... kind of), english and 
sometimes russian/tschech/... I like to add comments in latin when I find more 
than 2 languages in on sourcefile :)

Nik

> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 



-- 
Please do not email me anything that you are not comfortable also sharing with 
the NSA, CIA ...
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[spiralofhope]

On Thu, 29 Jul 2021 17:33:10 +0200
al3xu5  wrote:

> 11) Document and document and document all the code (vars, functions,
> errors etc. ... all)

It was mentioned earlier; variables and functions wouldn't need much
(if any) documentation if they were long and descriptive.

I like using short phrases, and sometimes I use poor grammar because it
supports consistency between similar items.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Josef Grosch via Dng]

On 7/29/21 9:13 AM, tempforever wrote:

Is this commandment (the code of one subroutine fitting into one screen)
an absolute rule?  What about, for example, assembly-language
programming?  Must I buy a bigger screen? :-)
I will admit that I do very little assembly anymore, so this wouldn't
affect me much now.  I have many routines in C that take up many lines
(more than a screen).  I guess I could "compress" them into fewer lines
since the language allows for that, but there goes the readability!
Personally, I fail on this point many times.  Sometimes I use more
instructions than required just to make it more perspicuous what the
code is doing, but I suppose that is breaking rule #1 then!

tito via Dng wrote:



I think the idea that is being express could be better stated. The 
"rule" that the subroutine / function / method should fit on one screen 
is very much dependent on the size of the monitor, the orientation 
(landscape or portrait) , and the size of the font used (some of us old 
farts need a BIGGER font). I think what tito was trying to say was, like 
all things *nix, the method should do one things and do it well. Again, 
basic principles, KISS



Josef

--
Josef Grosch| Another day closer |
jgro...@mooseriver.com  | to Redwood Heaven  | Berkeley, Ca.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[tempforever]

Is this commandment (the code of one subroutine fitting into one screen)
an absolute rule?  What about, for example, assembly-language
programming?  Must I buy a bigger screen? :-)
I will admit that I do very little assembly anymore, so this wouldn't
affect me much now.  I have many routines in C that take up many lines
(more than a screen).  I guess I could "compress" them into fewer lines
since the language allows for that, but there goes the readability! 
Personally, I fail on this point many times.  Sometimes I use more
instructions than required just to make it more perspicuous what the
code is doing, but I suppose that is breaking rule #1 then!

tito via Dng wrote:
> On Tue, 27 Jul 2021 13:07:01 -0400
> Steve Litt  wrote:
>
>> tito via Dng said on Tue, 27 Jul 2021 08:26:03 +0200
>>
>>
>>> Ten Commandments
>>>
>>>  1) use the least amount of code possible
>>>  2) try harder and go to point 1
>>>  3) if the code doesn't fit into one screen go to point 2
>> Do you mean if the code OF ONE SUBROUTINE doesn't fit into one screen,
>> go to point 2?
> Yes. I have a big screen nowadays 
>
>> Thanks,
>>
>> SteveT
>>
>> Steve Litt 
>> Spring 2021 featured book: Troubleshooting Techniques of the Successful
>> Technologist http://www.troubleshooters.com/techniques
>> ___
>> Dng mailing list
>> Dng@lists.dyne.org
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[al3xu5]

Tue, 27 Jul 2021 07:31:12 -0700 - Josef Grosch :

> On 7/26/21 11:26 PM, tito via Dng wrote:
> > On Mon, 26 Jul 2021 22:53:02 -0400
> > Steve Litt  wrote:
> >  
> >> Hendrik Boom said on Mon, 26 Jul 2021 17:21:24 -0400
> >>  
> >>> On Mon, Jul 26, 2021 at 11:48:53AM -0400, Steve Litt wrote:  
>  Andreas Messer said on Mon, 26 Jul 2021 09:38:23 +0200
> 
>   
> > My feeling is, that you can not simply teach someone how to write
> > safe software.  
>  Why not? You can teach a person to do anything else. But maybe not
>  in college, because college is built to make money, not to teach.
>  Consider the average textbook and compare to the average "For
>  Dummies" book. The former makes the subject matter look incredibly
>  complex, justifying the professor. The latter makes it easy to
>  learn.
> 
>  What is needed is a curated document explaining the five or ten or
>  twenty things you need to do to be secure, and then how to achieve
>  them in a practical world. Let's start with input field cleansing
>  and protection from errant pointers and buffer overflow. There are
>  many more:  
> >>> Knowing you, you probably already have a draft of such a document
> >>> lying around.  
> >> Not that I know of. That's why I'm starting at the level of a simple
> >> list.
> >>
> >> SteveT
> >>
> >> Steve Litt
> >> Spring 2021 featured book: Troubleshooting Techniques of the
> >> Successful Technologist http://www.troubleshooters.com/techniques  
> > Hi,
> >
> > Ten Commandments
> >
> >1) use the least amount of code possible
> >2) try harder and go to point 1
> >3) if the code doesn't fit into one screen go to point 2
> >4) always initialize your vars at declaration time
> >5) always set your vars to NULL after freeing them
> >6) always check error codes of the functions you call and something
> > appropriate 7) add comments about what and why you did (that ugly hack)
> >8) use meaningful (to others) names for your functions and vars
> >9) your code must be readable to others like a children's book
> > 10) if you don't know how to solve it, look what others did, then do
> > it your way (or forget Ctrl-C)
> >
> > these are the few rules I used when I did a little programming in the
> > past. So tell me yours...
> >
> > Ciao,
> > Tito
> >  
> 
> I've done a fair bit of programming in my career, (FORTRAN, COBOL, C, 
> Pascal, Java, Perl, Python) and I've also have my rules to programming.
> 
> 
> 1) KISS (Keep It Simple Stupid) Clever code always comes back to bite 
> you in the ass. Simplicity is a beautiful thing.
> 
> 2) White space is free, use it to make the code readable.
> 
> 3) Pick a coding style and stick to it, I personally prefer the One True 
> coding style. Most languages have a tool like Beautify that can be 
> configured to format your code to your coding style.
> 
> 4) If a block of code gets repeated 2 or more time break it out as a 
> function or a method.
> 
> 5) Most languages have a Lint type tool, use it often.
> 
> 6) Use the system and languages libraries. Never try to re-write them, 
> it will only lead to more bugs and rabbit holes. Same goes for libraries 
> from other projects, they have had the benefit of many eyes looking at 
> their code.
> 
> 7) Pay attention to the scope of variables and functions.
> 
> 8) Use a revision control system like Git to check code in on a regular 
> basis into a branch for a coding session, not into the main branch. 
> Working in a branch lets you figure out what really works and only when 
> everything is correct then merge into the main branch. I usually do a 
> pull at the beginning of a coding session and a push at the end.
> 
> 
> I'm sure I have more but I'm low on coffee.


9) Write code to debug and log 

10) Handle all kind of errors

11) Document and document and document all the code (vars, functions,
errors etc. ... all)

12) Write and run accurate tests for each routine and the whole code

13) Clearly specify the license(s) for each piece of code

... sure there is more but now I am low on coffee too...

regards
al3xu5

-- 
Say NO to copyright, patents, trademarks and industrial design
restrictions!


Public GPG/PGP key: 8FC2 3121 2803 86E9 F7D8  B624 DA50 835B 2624 A36B


pgpxxsb4icXXG.pgp
Description: Firma digitale OpenPGP
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[tito via Dng]

On Tue, 27 Jul 2021 13:11:47 -0400
Steve Litt  wrote:

> tito via Dng said on Tue, 27 Jul 2021 08:26:03 +0200
> 
> 
> >Ten Commandments
> >
> >  1) use the least amount of code possible
> >  2) try harder and go to point 1
> >  3) if the code doesn't fit into one screen go to point 2
> >  4) always initialize your vars at declaration time
> >  5) always set your vars to NULL after freeing them
> >  6) always check error codes of the functions you call and something
> > appropriate 
> > 7) add comments about what and why you did (that ugly
> > hack) 
> > 8) use meaningful (to others) names for your functions and vars
> >  9) your code must be readable to others like a children's book
> >10) if you don't know how to solve it, look what others did, then do
> >it your way (or forget Ctrl-C)
> 
> Thanks Tito,
> 
> This is a good part of what I was asking for. I'd like to add that you
> need to cleanse and length-check any user input that comes in.

Yes, forgot about that one, was a pain when I did my first 
and last (til now) C + GTK + LIBMYSQL program for win32.

Tito   

> SteveT
> 
> Steve Litt 
> Spring 2021 featured book: Troubleshooting Techniques of the Successful
> Technologist http://www.troubleshooters.com/techniques
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[tito via Dng]

On Tue, 27 Jul 2021 13:07:01 -0400
Steve Litt  wrote:

> tito via Dng said on Tue, 27 Jul 2021 08:26:03 +0200
> 
> 
> >Ten Commandments
> >
> >  1) use the least amount of code possible
> >  2) try harder and go to point 1
> >  3) if the code doesn't fit into one screen go to point 2
> 
> Do you mean if the code OF ONE SUBROUTINE doesn't fit into one screen,
> go to point 2?

Yes. I have a big screen nowadays 

> Thanks,
> 
> SteveT
> 
> Steve Litt 
> Spring 2021 featured book: Troubleshooting Techniques of the Successful
> Technologist http://www.troubleshooters.com/techniques
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Steve Litt]

Josef Grosch via Dng said on Tue, 27 Jul 2021 07:31:12 -0700


>7) Pay attention to the scope of variables and functions.

LOL. When I was a lot younger and stupider, my C code enabling 40 data
entry people to input data crashed once or twice a day, costing about
1/2 hour of work for each (20 hours of work gone per crash). My
co-worker and I finally found the problem, which follows:

==
#include 
#include 

char * double_string(const char * string_in)
{
char buffer[2000];  /* way big enough */
strcpy(buffer, string_in);
strcpy(buffer + strlen(string_in), string_in);
return buffer;
}

int main(int argc, char * argv[])
{
char * newstring = double_string("the quick, sly fox");
do_lots_of_other_stuff();
printf("%s\n", newstring); // Why wrong output?
return 0;
}
==

I never did THAT again!

SteveT

Steve Litt 
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Steve Litt]

Miles Fidelman said on Tue, 27 Jul 2021 09:59:49 -0400

 Andreas Messer said on Mon, 26 Jul 2021 09:38:23 +0200

  
> My feeling is, that you can not simply teach someone how to write
> safe software.  
 Why not? You can teach a person to do anything else. But maybe not
 in college, because college is built to make money, not to teach.
 Consider the average textbook and compare to the average "For
 Dummies" book. The former makes the subject matter look incredibly
 complex, justifying the professor. The latter makes it easy to
 learn.

 What is needed is a curated document explaining the five or ten or
 twenty things you need to do to be secure, and then how to achieve
 them in a practical world. Let's start with input field cleansing
 and protection from errant pointers and buffer overflow. There are
 many more:  

>Because there will always be new failure modes & vulnerabilities - it 
>comes with any complex engineering activity.
>
>You can teach people to avoid KNOWN failure modes & vulnerabilities,
>and establish processes and methods to avoid them (e.g., tooling,
>testing, design reviews, etc.) - but there will always be new ones -
>that can only be detected in the breach.  

Exactly! The preceding list can't address 100% of exploits. The only
thing it can do is address the 90% (my guesstimate) of exploits,
leaving the remaining 10% to require ultra-intelligent badguys and rule
out the army of script-kiddies roaming the net.

As an analogy, if there were a technique to prevent 90% of car crashes,
you'd make that move and then figure out how to reduce the remaining
10%.

> Good engineers can, perhaps,
>see and avoid some.  Penetration testing can help find others before
>fielding. But ultimately, there will always be unsafe code in the
>field - that will only be detected in the breach.

Your preceding paragraph is true without a doubt. The best we can hope
for is to make it trivial for every amateur and beginning professional
coder to learn how to prevent the majority of exploits.


SteveT

Steve Litt 
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Steve Litt]

tito via Dng said on Tue, 27 Jul 2021 08:26:03 +0200


>Ten Commandments
>
>  1) use the least amount of code possible
>  2) try harder and go to point 1
>  3) if the code doesn't fit into one screen go to point 2
>  4) always initialize your vars at declaration time
>  5) always set your vars to NULL after freeing them
>  6) always check error codes of the functions you call and something
> appropriate 
> 7) add comments about what and why you did (that ugly
> hack) 
> 8) use meaningful (to others) names for your functions and vars
>  9) your code must be readable to others like a children's book
>10) if you don't know how to solve it, look what others did, then do
>it your way (or forget Ctrl-C)

Thanks Tito,

This is a good part of what I was asking for. I'd like to add that you
need to cleanse and length-check any user input that comes in.

SteveT

Steve Litt 
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Steve Litt]

tito via Dng said on Tue, 27 Jul 2021 08:26:03 +0200


>Ten Commandments
>
>  1) use the least amount of code possible
>  2) try harder and go to point 1
>  3) if the code doesn't fit into one screen go to point 2

Do you mean if the code OF ONE SUBROUTINE doesn't fit into one screen,
go to point 2?

Thanks,

SteveT

Steve Litt 
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Josef Grosch via Dng]

On 7/26/21 11:26 PM, tito via Dng wrote:

On Mon, 26 Jul 2021 22:53:02 -0400
Steve Litt  wrote:


Hendrik Boom said on Mon, 26 Jul 2021 17:21:24 -0400


On Mon, Jul 26, 2021 at 11:48:53AM -0400, Steve Litt wrote:

Andreas Messer said on Mon, 26 Jul 2021 09:38:23 +0200

   

My feeling is, that you can not simply teach someone how to write
safe software.

Why not? You can teach a person to do anything else. But maybe not in
college, because college is built to make money, not to teach.
Consider the average textbook and compare to the average "For
Dummies" book. The former makes the subject matter look incredibly
complex, justifying the professor. The latter makes it easy to learn.

What is needed is a curated document explaining the five or ten or
twenty things you need to do to be secure, and then how to achieve
them in a practical world. Let's start with input field cleansing and
protection from errant pointers and buffer overflow. There are many
more:

Knowing you, you probably already have a draft of such a document
lying around.

Not that I know of. That's why I'm starting at the level of a simple
list.

SteveT

Steve Litt
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques

Hi,

Ten Commandments

   1) use the least amount of code possible
   2) try harder and go to point 1
   3) if the code doesn't fit into one screen go to point 2
   4) always initialize your vars at declaration time
   5) always set your vars to NULL after freeing them
   6) always check error codes of the functions you call and something 
appropriate
   7) add comments about what and why you did (that ugly hack)
   8) use meaningful (to others) names for your functions and vars
   9) your code must be readable to others like a children's book
10) if you don't know how to solve it, look what others did, then do it your 
way (or forget Ctrl-C)

these are the few rules I used when I did a little programming in the past.
So tell me yours...

Ciao,
Tito



I've done a fair bit of programming in my career, (FORTRAN, COBOL, C, 
Pascal, Java, Perl, Python) and I've also have my rules to programming.



1) KISS (Keep It Simple Stupid) Clever code always comes back to bite 
you in the ass. Simplicity is a beautiful thing.


2) White space is free, use it to make the code readable.

3) Pick a coding style and stick to it, I personally prefer the One True 
coding style. Most languages have a tool like Beautify that can be 
configured to format your code to your coding style.


4) If a block of code gets repeated 2 or more time break it out as a 
function or a method.


5) Most languages have a Lint type tool, use it often.

6) Use the system and languages libraries. Never try to re-write them, 
it will only lead to more bugs and rabbit holes. Same goes for libraries 
from other projects, they have had the benefit of many eyes looking at 
their code.


7) Pay attention to the scope of variables and functions.

8) Use a revision control system like Git to check code in on a regular 
basis into a branch for a coding session, not into the main branch. 
Working in a branch lets you figure out what really works and only when 
everything is correct then merge into the main branch. I usually do a 
pull at the beginning of a coding session and a push at the end.



I'm sure I have more but I'm low on coffee.


Josef

--
Josef Grosch| Another day closer |
jgro...@mooseriver.com  | to Redwood Heaven  | Berkeley, Ca.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Miles Fidelman]

Andreas Messer said on Mon, 26 Jul 2021 09:38:23 +0200

   

My feeling is, that you can not simply teach someone how to write
safe software.

Why not? You can teach a person to do anything else. But maybe not in
college, because college is built to make money, not to teach.
Consider the average textbook and compare to the average "For
Dummies" book. The former makes the subject matter look incredibly
complex, justifying the professor. The latter makes it easy to learn.

What is needed is a curated document explaining the five or ten or
twenty things you need to do to be secure, and then how to achieve
them in a practical world. Let's start with input field cleansing and
protection from errant pointers and buffer overflow. There are many
more:
Because there will always be new failure modes & vulnerabilities - it 
comes with any complex engineering activity.


You can teach people to avoid KNOWN failure modes & vulnerabilities, and 
establish processes and methods to avoid them (e.g., tooling, testing, 
design reviews, etc.) - but there will always be new ones - that can 
only be detected in the breach.  Good engineers can, perhaps, see and 
avoid some.  Penetration testing can help find others before fielding.  
But ultimately, there will always be unsafe code in the field - that 
will only be detected in the breach.


As von Moltke put it, "no plan survives contact with the enemy."  It 
probably has something to do with computability (P/NP and all that.)


We could learn from the way the aerospace industry responds to plane 
crashes, though.  And, maybe, trash "agile" and go back to design 
processes that got us to the Moon (you know, serious, step-by-step, 
design, document, review, test).


Miles Fidelman


--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
In our lab, theory and practice are combined:
nothing works and no one knows why.  ... unknown

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[g4sra via Dng]

On Tuesday, July 27th, 2021 at 7:26 AM, tito via Dng  wrote:
> On Mon, 26 Jul 2021 22:53:02 -0400
> Steve Litt sl...@troubleshooters.com wrote:
> > Hendrik Boom said on Mon, 26 Jul 2021 17:21:24 -0400
> > > On Mon, Jul 26, 2021 at 11:48:53AM -0400, Steve Litt wrote:
> > > > Andreas Messer said on Mon, 26 Jul 2021 09:38:23 +0200
> > > > 

> > > > > My feeling is, that you can not simply teach someone how to write 
> > > > > safe software.
> > > > 

> > > > Why not? You can teach a person to do anything else. But maybe not in
> > > > college, because college is built to make money, not to teach.
> > > > Consider the average textbook and compare to the average "For
> > > > Dummies" book. The former makes the subject matter look incredibly
> > > > complex, justifying the professor. The latter makes it easy to learn.
> > > > What is needed is a curated document explaining the five or ten or
> > > > twenty things you need to do to be secure, and then how to achieve
> > > > them in a practical world. Let's start with input field cleansing and
> > > > protection from errant pointers and buffer overflow. There are many
> > > > more:
> > > 

> > > Knowing you, you probably already have a draft of such a document lying 
> > > around.
> > 

> > Not that I know of. That's why I'm starting at the level of a simple list.
> > 

> > SteveT
> 

> Hi,
> 

> Ten Commandments
> 

> 1.  use the least amount of code possible
> 2.  try harder and go to point 1
> 3.  if the code doesn't fit into one screen go to point 2
> 4.  always initialize your vars at declaration time
> 5.  always set your vars to NULL after freeing them
> 6.  always check error codes of the functions you call and something 
> appropriate
> 7.  add comments about what and why you did (that ugly hack)
> 8.  use meaningful (to others) names for your functions and vars
> 9.  your code must be readable to others like a children's book
> 10.  if you don't know how to solve it, look what others did, then do it your 
> way (or forget Ctrl-C)
> 

> these are the few rules I used when I did a little programming in the past
> So tell me yours...
> 

> Ciao, 

> Tito

Applying all those rules to all programming languages for all situations will 
not be a guarantee of a quality software product.
Also as Tito would probably admit that list is far from complete.
The issue is determining what rules to apply and when.


If anyone here is interested in learning programming and does not know where to 
start...my suggestion would be as follows

Look up the definition of each word of the Software Developer's Mantra below in 
relation to software development
(they are in alphabetical order purely for the mnemonic effect and are all of 
equal importance).

Consider and apply that definition to the use of the *programming language* and 
the *specific application being developed*.
This should be done iteratively during authoring, line by line, first to the 
expression, the whole function, then the module, throughout the whole program.

Software Developer's Mantra
~~~
completeness conciseness
high-cohesion low-coupling
resilience robustness
validation verification

This will still work with whatever design methodology you have been forced to 
work under, be it Agile, Scrum, Waterfall, Bohemes Spiral, etc. etc.

For example .. look up high-cohesion
https://en.wikipedia.org/wiki/Cohesion_(computer_science)
Apply the concept to every line as you write it.

NB. There is a lot more to software development than this, but following the 
mantra can help you produce significantly better code.


publickey - g4sra@protonmail.com - 0x42E94623.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[tito via Dng]

On Mon, 26 Jul 2021 22:53:02 -0400
Steve Litt  wrote:

> Hendrik Boom said on Mon, 26 Jul 2021 17:21:24 -0400
> 
> >On Mon, Jul 26, 2021 at 11:48:53AM -0400, Steve Litt wrote:
> >> Andreas Messer said on Mon, 26 Jul 2021 09:38:23 +0200
> >> 
> >>   
> >> >My feeling is, that you can not simply teach someone how to write
> >> >safe software.   
> >> 
> >> Why not? You can teach a person to do anything else. But maybe not in
> >> college, because college is built to make money, not to teach.
> >> Consider the average textbook and compare to the average "For
> >> Dummies" book. The former makes the subject matter look incredibly
> >> complex, justifying the professor. The latter makes it easy to learn.
> >> 
> >> What is needed is a curated document explaining the five or ten or
> >> twenty things you need to do to be secure, and then how to achieve
> >> them in a practical world. Let's start with input field cleansing and
> >> protection from errant pointers and buffer overflow. There are many
> >> more:  
> >
> >Knowing you, you probably already have a draft of such a document
> >lying around.
> 
> Not that I know of. That's why I'm starting at the level of a simple
> list.
> 
> SteveT
> 
> Steve Litt 
> Spring 2021 featured book: Troubleshooting Techniques of the Successful
> Technologist http://www.troubleshooters.com/techniques

Hi,

Ten Commandments

  1) use the least amount of code possible
  2) try harder and go to point 1
  3) if the code doesn't fit into one screen go to point 2
  4) always initialize your vars at declaration time
  5) always set your vars to NULL after freeing them
  6) always check error codes of the functions you call and something 
appropriate
  7) add comments about what and why you did (that ugly hack)
  8) use meaningful (to others) names for your functions and vars
  9) your code must be readable to others like a children's book
10) if you don't know how to solve it, look what others did, then do it your 
way (or forget Ctrl-C)

these are the few rules I used when I did a little programming in the past.
So tell me yours...

Ciao,
Tito








___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Steve Litt]

Hendrik Boom said on Mon, 26 Jul 2021 17:21:24 -0400

>On Mon, Jul 26, 2021 at 11:48:53AM -0400, Steve Litt wrote:
>> Andreas Messer said on Mon, 26 Jul 2021 09:38:23 +0200
>> 
>>   
>> >My feeling is, that you can not simply teach someone how to write
>> >safe software.   
>> 
>> Why not? You can teach a person to do anything else. But maybe not in
>> college, because college is built to make money, not to teach.
>> Consider the average textbook and compare to the average "For
>> Dummies" book. The former makes the subject matter look incredibly
>> complex, justifying the professor. The latter makes it easy to learn.
>> 
>> What is needed is a curated document explaining the five or ten or
>> twenty things you need to do to be secure, and then how to achieve
>> them in a practical world. Let's start with input field cleansing and
>> protection from errant pointers and buffer overflow. There are many
>> more:  
>
>Knowing you, you probably already have a draft of such a document
>lying around.

Not that I know of. That's why I'm starting at the level of a simple
list.

SteveT

Steve Litt 
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Hendrik Boom]

On Mon, Jul 26, 2021 at 11:48:53AM -0400, Steve Litt wrote:
> Andreas Messer said on Mon, 26 Jul 2021 09:38:23 +0200
> 
> 
> >My feeling is, that you can not simply teach someone how to write safe
> >software. 
> 
> Why not? You can teach a person to do anything else. But maybe not in
> college, because college is built to make money, not to teach. Consider
> the average textbook and compare to the average "For Dummies" book. The
> former makes the subject matter look incredibly complex, justifying the
> professor. The latter makes it easy to learn.
> 
> What is needed is a curated document explaining the five or ten or
> twenty things you need to do to be secure, and then how to achieve them
> in a practical world. Let's start with input field cleansing and
> protection from errant pointers and buffer overflow. There are many
> more:

Knowing you, you probably already have a draft of such a document
lying around.

-- hendrik

> It takes some effort to learn, but I doubt it's rocket science
> and one certainly doesn't need to come from a family who can fund
> college plus living expenses for 4 years, or 7, or whatever.
> 
> SteveT
> 
> Steve Litt 
> Spring 2021 featured book: Troubleshooting Techniques of the Successful
> Technologist http://www.troubleshooters.com/techniques
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Steve Litt]

g4sra via Dng said on Mon, 26 Jul 2021 16:33:45 +

>On Monday, July 26th, 2021 at 4:48 PM, Steve Litt
> wrote:


>> Let's start with input field cleansing and
>> protection from errant pointers and buffer overflow. There are many
>> more:  

>Yeah, that's what they taught me at college :).

OK, now we're getting somewhere. What other specific things did
college teach you that you need to do to be secure? Write them here,
and we can start giving each other tips on *how* to do each. The
document can be published with a license permitting universal use
but not universal ability to change (we don't want bullshit creeping
in), put it in a prominent place, and help the software world immensely.

SteveT

Steve Litt 
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[g4sra via Dng]

<--snip-->
> > > 

> > > Agreed, we must have all at least heard of Kevin Mitnick,
> There you go with assumptions, something you should never do. I have
> absolutely no idea who Kevin Mitnick is, I had never heard that name
> until you posted it.
> 

> Rowland

It wasn't my intention to be educational, my mistake ;)



publickey - g4sra@protonmail.com - 0x42E94623.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Rowland Penny via Dng]

On Mon, 2021-07-26 at 16:33 +, g4sra via Dng wrote:
> On Monday, July 26th, 2021 at 4:48 PM, Steve Litt <
> sl...@troubleshooters.com> wrote:
> > Andreas Messer said on Mon, 26 Jul 2021 09:38:23 +0200
> > 
> > > My feeling is, that you can not simply teach someone how to write
> > > safe software.
> > Why not? You can teach a person to do anything else. But maybe not
> > in
> > college, because college is built to make money, not to teach.
> > Consider
> > the average textbook and compare to the average "For Dummies" book.
> > The
> > former makes the subject matter look incredibly complex, justifying
> > the
> > professor. The latter makes it easy to learn.
> > What is needed is a curated document explaining the five or ten or
> > twenty things you need to do to be secure, and then how to achieve
> > them
> > in a practical world.
> Software is far too complex to be audited by following a fixed set of
> generic rules,
> otherwise someone would have already written software that can do
> exactly that.
> We have some tools, but they are incomplete and fallible.
> 
> The personality of the individual is key, which is why not anyone can
> learn to program safely.
> I witnessed an individual sail through and get top marks at college,
> they had an eidetic mind.
> They could recall any fact they had been told\read instantly and
> accurately.
> But they had no creativity and could be easily tripped up with the
> simplest of problems if they had not seen it before. 
> 
> 
> > Let's start with input field cleansing and
> > protection from errant pointers and buffer overflow. There are many
> > more:
> Yeah, that's what they taught me at college :).
> 
> > It takes some effort to learn, but I doubt it's rocket science
> Which is why they call it Computer Science, it's harder.
> Rocket Science has a formula for everything, even the top AI experts
> cannot formulate the intricacies of a Neural Net program.
> 
> > and one certainly doesn't need to come from a family who can fund
> > college plus living expenses for 4 years, or 7, or whatever.
> Agreed, we must have all at least heard of Kevin Mitnick, 

There you go with assumptions, something you should never do. I have
absolutely no idea who Kevin Mitnick is, I had never heard that name
until you posted it.

Rowland

> who as a teenager learnt from his dad, a security expert.
> How executing software processes what you enter into it is as much a
> security concern as the source code.
> > SteveT
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[g4sra via Dng]

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐

On Monday, July 26th, 2021 at 5:39 PM, Dr. Nikolaus Klepp  
wrote:

> Anno domini 2021 Mon, 26 Jul 16:33:45 +
> 

> g4sra via Dng scripsit:
> 

> > [...]
> > 

> > > It takes some effort to learn, but I doubt it's rocket science
> > > Which is why they call it Computer Science, it's harder.
> > > Rocket Science has a formula for everything, even the top AI experts 
> > > cannot formulate the intricacies of a Neural Net program.
> Why not? It's just a set of equations. Calling it "AI" might sell it to 
> marketing guys and polititians that definitly lack "NI", but that's about it.

It's no big secret, because none of the experts 'understand' the intricacies of 
the interactions of said equations.
A very quick google (or web search if you prefer), not bothered reading them 
myself, there may be better examples out there.

Tabloid style:
https://qz.com/865357/we-dont-understand-how-ai-make-most-decisions-so-now-algorithms-are-explaining-themselves/

Industry style:
https://simmtester.com/News/IndustryArticle/21626

> 

> Nik
> 





publickey - g4sra@protonmail.com - 0x42E94623.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Dr. Nikolaus Klepp]

Anno domini 2021 Mon, 26 Jul 16:33:45 +
 g4sra via Dng scripsit:
> [...]
> > It takes some effort to learn, but I doubt it's rocket science
> Which is why they call it Computer Science, it's harder.
> Rocket Science has a formula for everything, even the top AI experts cannot 
> formulate the intricacies of a Neural Net program.

Why not? It's just a set of equations. Calling it "AI" might sell it to 
marketing guys and polititians that definitly lack "NI", but that's about it.

Nik

> > and one certainly doesn't need to come from a family who can fund
> > college plus living expenses for 4 years, or 7, or whatever.
> Agreed, we must have all at least heard of Kevin Mitnick, who as a teenager 
> learnt from his dad, a security expert.
> How executing software processes what you enter into it is as much a security 
> concern as the source code.
> > 
> 
> > SteveT
> 
> 
> 



-- 
Please do not email me anything that you are not comfortable also sharing with 
the NSA, CIA ...
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[g4sra via Dng]

On Monday, July 26th, 2021 at 4:48 PM, Steve Litt  
wrote:
> Andreas Messer said on Mon, 26 Jul 2021 09:38:23 +0200
> 

> > My feeling is, that you can not simply teach someone how to write safe 
> > software.
> 

> Why not? You can teach a person to do anything else. But maybe not in
> college, because college is built to make money, not to teach. Consider
> the average textbook and compare to the average "For Dummies" book. The
> former makes the subject matter look incredibly complex, justifying the
> professor. The latter makes it easy to learn.
> What is needed is a curated document explaining the five or ten or
> twenty things you need to do to be secure, and then how to achieve them
> in a practical world.
Software is far too complex to be audited by following a fixed set of generic 
rules,
otherwise someone would have already written software that can do exactly that.
We have some tools, but they are incomplete and fallible.

The personality of the individual is key, which is why not anyone can learn to 
program safely.
I witnessed an individual sail through and get top marks at college, they had 
an eidetic mind.
They could recall any fact they had been told\read instantly and accurately.
But they had no creativity and could be easily tripped up with the simplest of 
problems if they had not seen it before. 


> Let's start with input field cleansing and
> protection from errant pointers and buffer overflow. There are many
> more:
Yeah, that's what they taught me at college :).

> It takes some effort to learn, but I doubt it's rocket science
Which is why they call it Computer Science, it's harder.
Rocket Science has a formula for everything, even the top AI experts cannot 
formulate the intricacies of a Neural Net program.

> and one certainly doesn't need to come from a family who can fund
> college plus living expenses for 4 years, or 7, or whatever.
Agreed, we must have all at least heard of Kevin Mitnick, who as a teenager 
learnt from his dad, a security expert.
How executing software processes what you enter into it is as much a security 
concern as the source code.
> 

> SteveT




publickey - g4sra@protonmail.com - 0x42E94623.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Steve Litt]

Andreas Messer said on Mon, 26 Jul 2021 09:38:23 +0200


>My feeling is, that you can not simply teach someone how to write safe
>software. 

Why not? You can teach a person to do anything else. But maybe not in
college, because college is built to make money, not to teach. Consider
the average textbook and compare to the average "For Dummies" book. The
former makes the subject matter look incredibly complex, justifying the
professor. The latter makes it easy to learn.

What is needed is a curated document explaining the five or ten or
twenty things you need to do to be secure, and then how to achieve them
in a practical world. Let's start with input field cleansing and
protection from errant pointers and buffer overflow. There are many
more: It takes some effort to learn, but I doubt it's rocket science
and one certainly doesn't need to come from a family who can fund
college plus living expenses for 4 years, or 7, or whatever.

SteveT

Steve Litt 
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Andreas Messer]

On Sun, Jul 25, 2021 at 07:51:50PM -0400, Steve Litt wrote:
> g4sra via Dng said on Sun, 25 Jul 2021 10:26:46 +
> 
> 
> >And this is why ever sice I entered the profession I have maintained
> >that programmers should be vetted and certified in a similar manner to
> >other professions such as doctors and lawyers, carrying a similar
> >social status. Only those with the appropriate qualification and
> >experience should be permitted to work in certain sectors. 
> 
> I'm glad you said "certain sectors". I'm glad there are other sectors
> (office automation comes to mind) where a guy who gets proficient with
> the computer on his kitchen table can get paid work, and learn there.
> Otherwise, programming would be restricted to folks rich enough for
> their parents to send them to college to learn programming, and then
> a triciary education to learn all the security, defense and engineering
> stuff, and like doctors and lawyers, they wouldn't start making any
> real money until their late 20's.
> 
> Programmers would be selected for family wealth, not for desire and
> aptitude.

My feeling is, that you can not simply teach someone how to write safe
software. It is to a great extend a matter of experience and character if
someone is able to do it or not. Experience means, you need to fall into 
the traps to understand whats going on and whats a bad design. Maybe kind
of pair programming can help. But in the end all developers are human and
need to start somewhere. Of course there should be continued trainings. 
And the second thing, nowadays not only managers but also developers are 
exposed to various kind of pressure. You need to resist to go the easy 
way or to be pushed in that direction by someone else. And this
every single day: "Can't we just... Customer is waiting!", "Distribution
already sold it, we need to have it (yesterday)...".

No one should think of himself being error-prone - certified or not. We're
all just humans and misdo. I believe most risks can be easily mitigated 
with some experienced members in the design phase and highly veteran testers 
who qualify the results. I also think, its not a good idea to divide
a software development work across to many different persons, there should
be developers which an understanding of the whole (embedded-)system.

If if would be allowing only highly conscientious people to develop
software and check their work multiple times by others it will still
contain errors. It has just become too complex. Coming back to the sensor 
above: 10 years ago it was sufficient to just send the sensor state every
10ms to some central control device. Today the same sensor (often based on
the same hardware, product owners think its just a matter of the
software) should send the data in 250µs intervals and at the same time, 
serve complex dynamic webpages with TLS encryption and full certificate
chain and send diagnostic or production related data to some IoT edge
server in order to enjoy management with colorful plots. And during that it
is expected to withstand an DoS attack. But the device is still used in the
same place, doing the same work. All these extra function are not
used in 99% of the cases, but its in the device just in case someone might
need it. And this adds complexity which adds bugs.

Most things today a profit driven, and result is, that management tries to
avoid any (in their eyes) unnecessary work by reusing existing but maybe 
much to complex code or designs, have one software for all usecases, 
implement "workarounds" or simply omits tests. To be honest, price
pressure is often applied from the outside - e.g. my employer develops
some SoC and although these grow in performance and shrink in size, power
and extra parts. With every new device, customers expect them to become
cheaper and cheaper and get the software for free.

cheers,
Andreas

-- 
gnuPG keyid: 8C2BAF51
fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51


signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Steve Litt]

g4sra via Dng said on Sun, 25 Jul 2021 10:26:46 +


>And this is why ever sice I entered the profession I have maintained
>that programmers should be vetted and certified in a similar manner to
>other professions such as doctors and lawyers, carrying a similar
>social status. Only those with the appropriate qualification and
>experience should be permitted to work in certain sectors. 

I'm glad you said "certain sectors". I'm glad there are other sectors
(office automation comes to mind) where a guy who gets proficient with
the computer on his kitchen table can get paid work, and learn there.
Otherwise, programming would be restricted to folks rich enough for
their parents to send them to college to learn programming, and then
a triciary education to learn all the security, defense and engineering
stuff, and like doctors and lawyers, they wouldn't start making any
real money until their late 20's.

Programmers would be selected for family wealth, not for desire and
aptitude.

As long as most sectors let anybody who can write code write code,
programming remains a great source of upward mobility, and if a well
paid office automation programmer wants to become a medical equipment
programmer, he or she can then take courses and get a cert while still
earning a good living.

When I busted into programming, the most common traits of my fellow
programmers were that they played musical instruments, rode
bicycles, and had a real talent and desire for programming. Back then,
when I interviewed new programmers with 4 year degrees, they couldn't
code their way out of a paper bag.

SteveT

Steve Litt 
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[g4sra via Dng]

On Sunday, July 25th, 2021 at 6:53 PM, Simon Hobson  
wrote:
> Andreas Messer a...@bastelmap.de wrote:
> 

> > Once we had a crash in
> > simple limit switch device. As a result the high-rack robot pushed a
> > pallet in 15m height out of the rack. Fortunately, it was just another
> > robot which was destroyed (stood just below) - not a human being. Still
> > a very expensive case for the company. So I'm used implement a lot of
> > checks :-). (Actually we even don't use heap allocation after booting
> > the firmware)
> 

> Back in the 90s I had an acquaintance that did a lot of consulting for sites 
> with "management issues" and running "big iron". He got a jolly to see a site 
> that was run by systems from that vendor - the very early days of warehouse 
> automation. High bar warehousing, automated forklifts, with operators riding 
> along to move boxes between pallet on the forks and pallet on the racks - it 
> was a highly seasonal business, and in the run up to Christmas they be 
> getting order in in all sorts of quantities, putting a small box on a pallet 
> is highly inefficient so the need for manual handling to combine multiple 
> shipments onto one pallet on the racks.
> Apparently the average stay before the operators quit from the stress was 
> only 3 months !
> Then one day a forklift went wrong - fortunately with no operator on board. 
> It accelerated in an uncontrolled manner until it crashed through the side of 
> the building and fell over in the field next door - at which point, all the 
> operators walked out !
> 

> g4sra via Dng dng@lists.dyne.org wrote:
> 

> > There is nothing stopping me for applying for systems programming work in 
> > Nuclear Power Stations, Air Traffic Control, Industrial Robotics, etc...
> Yes, but if you look a little deeper, in that sort of industry the 
> programmers don't get to "just get on with it".
It doesn't read like you have been exposed to the same industry working 
practices I have, because that is exactly what happens until deadlines are not 
met.
> The higher the risk, the higher the degree of risk management.
And the personnel performing the risk management are of no greater standing 
that the personnel writing the software.
> By the time the programmer gets to write code, there's been a lot of safety 
> based design - and when they've written the code, there's a lot of testing 
> and assurance before it can go live.
No. There is 'testing and assurance' performed to the level agreed during the 
planning stage, planned by personnel of no greater standing...
> Of course, if you are Boeing and designing systems for aircraft - then it 
> seems it's a different matter !
> 

> Simon
> 


Maybe things have changed in the last ten years without my knowledge since I 
fulfilled the role of Security Auditor without any formal certification, 
reporting to the Board of an International Telecommunications company, but I 
doubt it.

Put more simplistically
It does not how many spelling checks are put in place if the spelling checkers 
cannot spell.
or as I prefer
Monkeys checking the work of Monkeys designed by Monkeys is not going to 
guarantee quality, it is only going to guarantee the slinging of faeces.



publickey - g4sra@protonmail.com - 0x42E94623.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Simon Hobson]

Andreas Messer  wrote:

> Once we had a crash in
> simple limit switch device. As a result the high-rack robot pushed a
> pallet in 15m height out of the rack. Fortunately, it was just another
> robot which was destroyed (stood just below) - not a human being. Still 
> a very expensive case for the company. So I'm used implement a lot of 
> checks :-). (Actually we even don't use heap allocation after booting 
> the firmware)

Back in the 90s I had an acquaintance that did a lot of consulting for sites 
with "management issues" and running "big iron". He got a jolly to see a site 
that was run by systems from that vendor - the very early days of warehouse 
automation. High bar warehousing, automated forklifts, with operators riding 
along to move boxes between pallet on the forks and pallet on the racks - it 
was a highly seasonal business, and in the run up to Christmas they be getting 
order in in all sorts of quantities, putting a small box on a pallet is highly 
inefficient so the need for manual handling to combine multiple shipments onto 
one pallet on the racks.
Apparently the average stay before the operators quit from the stress was only 
3 months !
Then one day a forklift went wrong - fortunately with no operator on board. It 
accelerated in an uncontrolled manner until it crashed through the side of the 
building and fell over in the field next door - at which point, all the 
operators walked out !


g4sra via Dng  wrote:

> There is nothing stopping *me* for applying for systems programming work in 
> Nuclear Power Stations, Air Traffic Control, Industrial Robotics, etc...


Yes, but if you look a little deeper, in that sort of industry the programmers 
don't get to "just get on with it". The higher the risk, the higher the degree 
of risk management. By the time the programmer gets to write code, there's been 
a lot of safety based design - and when they've written the code, there's a lot 
of testing and assurance before it can go live.
Of course, if you are Boeing and designing systems for aircraft - then it seems 
it's a different matter !

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[g4sra via Dng]

<--snip-->
> Why I'm so critical about letting it crash: I typically deal with stack
> sizes of no more around 2-8kB in automation devices and have to be careful
> with that. You can't simply let a newspaper printing machine's motor control
> crash, 1000's of newspaper pages would be trashed. Once we had a crash in 

> simple limit switch device. As a result the high-rack robot pushed a 

> pallet in 15m height out of the rack. Fortunately, it was just another
> robot which was destroyed (stood just below) - not a human being. Still 

> a very expensive case for the company.
<--snip-->

And this is why ever sice I entered the profession I have maintained that 
programmers should be vetted and certified in a similar manner to other 
professions such as doctors and lawyers, carrying a similar social status.
Only those with the appropriate qualification and experience should be 
permitted to work in certain sectors.
There is nothing stopping *me* for applying for systems programming work in 
Nuclear Power Stations, Air Traffic Control, Industrial Robotics, etc...
I have personal knowledge of a College classmate who went on to write Air 
Traffic Control software, personally I would not trust him to write an App for 
my phone (but would be the first person to call if organising a party).

People are going to continue to die until this change happens.

publickey - g4sra@protonmail.com - 0x42E94623.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Andreas Messer]

On Sat, Jul 24, 2021 at 05:35:10PM +0200, Didier Kryn wrote:
>     However the manual of alloca() states that "There is no error
> indication if the stack  frame  cannot  be  extended." If the same would
> happen with automatic variables, I would expect a crash; otherwise it
> would be a serious flaw in the compiler. According to you there is such
> a flaw?

I have just made a short experiment. On linux, typical stack size is
8MB ( ulimit -s). So using the following test program:

stack_overflow.c:


#include 
#include 

void 
test(int size, int use_it)
{
#if 1
  volatile int var[size/sizeof(int)];
#else
  volatile int* var = alloca(size);
#endif

  if(use_it)
var[0] = 0;
}

int 
main(int argc, char* argv[])
{
  long size   = argc > 1 ? atoi(argv[1]) : 1024;
  long use_it = argc > 2 ? atoi(argv[2]) : 0;

  printf("Will be allocating %ldkb stackframe %s access\n", size, use_it ? 
"with" : "without" );

  test(size*1024, use_it);
}


I get the following results:

...:/tmp$ gcc -o stack_overflow stack_overflow.c 
...:/tmp$ ./stack_overflow 16000 0
Will be allocating 16000kb stackframe without access
...:/tmp$ ./stack_overflow 16000 1
Will be allocating 16000kb stackframe with access
Speicherzugriffsfehler
...:/tmp$ gcc -o stack_overflow stack_overflow.c -fstack-check
...:/tmp$ ./stack_overflow 16000 0
Will be allocating 16000kb stackframe without access
Speicherzugriffsfehler
...:/tmp$ ./stack_overflow 8000 0
Will be allocating 8000kb stackframe without access


So if -fstack-overflow is not used, the program will crash only if 
memory is actually accessed out of bounds of the stack memory. Indeed,
accessing the last instead of the first array element does not crash
at all.

With -fstack-overflow it will already crash on allocation of the array. 
(as expected) 

When using the alloca() way, I get identical results.

Why I'm so critical about letting it crash: I typically deal with stack
sizes of no more around 2-8kB in automation devices and have to be careful
with that. You can't simply let a newspaper printing machine's motor control
crash, 1000's of newspaper pages would be trashed. Once we had a crash in
simple limit switch device. As a result the high-rack robot pushed a
pallet in 15m height out of the rack. Fortunately, it was just another
robot which was destroyed (stood just below) - not a human being. Still 
a very expensive case for the company. So I'm used implement a lot of 
checks :-). (Actually we even don't use heap allocation after booting 
the firmware)

cheers,
Andreas

-- 
gnuPG keyid: 8C2BAF51
fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51


signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Didier Kryn]

Le 22/07/2021 à 20:53, Andreas Messer a écrit :
> Hi,
>
> On Thu, Jul 22, 2021 at 07:53:58AM +0200, Didier Kryn wrote:
>>     There's a choice of options in GCC to deal with stack protection.
>> Eg:  -fstack-check
>>
>>     Plus a bunch of macros.
>>
>>     They all deal with allocation of automatic variables. For alloca(),
>> instead, there's explicitely no check.
> I don't find any reference about automatic variables in the docs regarding
> this topic.
    AFAIK, in the C language, stack == automatic variables.
>  Actually, the description of gcc's alloca() builtin states that 
> it behaves similar to automatic variables.

    This only means that it takes space from the stack. I've read also
that using it together with automatic variables of dynamic size, or,
even, embedded control blocks, is UB. Which means the compiler and
runtime are not properly informed. That said, it is possible that
compiler authors have made progress on this matter without updating the
documentation.

>  However, all these macros will 
> not prevent you from stack overflow but only help you to detect one when it 
> already happened. Also, the way gcc implements the check (probing SP) works 
> for alloca and for automatic variables in the same way. 
>
> However, once you have detected a stack overflow, your application is 
> in an inconsistent state. Of course you can implement some kind of rescue.
> (e.g using libsigsev) But you have to do a clean rewind of your app
> state back to state before the overflow occurred. This can become quite
> complex and hard to maintain. And then your're back to state before stack
> overflow, but what is the application supposed to do then? Log and ignore
> the request? Terminate? Ask the User? 
>
> The point is, an application should be designed such that a stack overflow
> just can not occur. And this implies length checking, regardless if using
> automatic vars or alloca.
    There is always something safer than UB: crash.
>
>>     In addition, the compiler is not informed of the invocation of
>> alloca(); therefore the space allocated to non-static automatic
>> variables may overlap with the space "allocated" by alloca().
> No. This is wrong alloca() is implemented as compiler builtin and
> does exactly the same as GCC does when allocating automatic vars on the
> stack.
>
> Prove: https://godbolt.org/z/abqK4T43c

> The generated machine code is identical including the stack overflow
> checking code.

    Generated code is normally not a proof. In the job of a compiler,
generating code is not necessarily the biggest part. Compile-time
controls and the generation of runtime checking code, when necessary,
are also essential. Here you tell the runtime verifications are the same
and I believe you - I don't know arm assembler; I used to read/write
assembler for PDP15 and IBM370 but it was  30-40 years ago (~:

    However the manual of alloca() states that "There is no error
indication if the stack  frame  cannot  be  extended." If the same would
happen with automatic variables, I would expect a crash; otherwise it
would be a serious flaw in the compiler. According to you there is such
a flaw?

    Cheers.

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Andreas Messer]

Hi,

On Thu, Jul 22, 2021 at 07:53:58AM +0200, Didier Kryn wrote:
>     There's a choice of options in GCC to deal with stack protection.
> Eg:  -fstack-check
> 
>     Plus a bunch of macros.
> 
>     They all deal with allocation of automatic variables. For alloca(),
> instead, there's explicitely no check.

I don't find any reference about automatic variables in the docs regarding
this topic. Actually, the description of gcc's alloca() builtin states that 
it behaves similar to automatic variables. However, all these macros will 
not prevent you from stack overflow but only help you to detect one when it 
already happened. Also, the way gcc implements the check (probing SP) works 
for alloca and for automatic variables in the same way. 

However, once you have detected a stack overflow, your application is 
in an inconsistent state. Of course you can implement some kind of rescue.
(e.g using libsigsev) But you have to do a clean rewind of your app
state back to state before the overflow occurred. This can become quite
complex and hard to maintain. And then your're back to state before stack
overflow, but what is the application supposed to do then? Log and ignore
the request? Terminate? Ask the User? 

The point is, an application should be designed such that a stack overflow
just can not occur. And this implies length checking, regardless if using
automatic vars or alloca.

>     In addition, the compiler is not informed of the invocation of
> alloca(); therefore the space allocated to non-static automatic
> variables may overlap with the space "allocated" by alloca().

No. This is wrong alloca() is implemented as compiler builtin and
does exactly the same as GCC does when allocating automatic vars on the
stack.

Prove: https://godbolt.org/z/abqK4T43c

The generated machine code is identical including the stack overflow
checking code.

cheers,
Andreas
-- 
gnuPG keyid: 8C2BAF51
fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51


signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Didier Kryn]

Le 21/07/2021 à 21:08, Andreas Messer a écrit :
> On Wed, Jul 21, 2021 at 02:36:16PM +0200, Didier Kryn wrote:
>> added (by gcc ?) to work around a missing feature of the C language:
>> dynamic allocation on the stack. This lack has disapeared many years ago
>> ( don't know with which version of the C standard) , with the following
>> form of allocation:
>>
>> ...
>>
>> n = 2x+1;
>>
>> {
>>
>>     int array[n];
>>
>>     ...
>>
>> }
>>
>>     And, therefore, alloca() should be removed.
> Well, alloca(n*sizeof(int)) and your suggestion both do the same in that 
> they allocate memory from stack without any checking. Thus both will 
> show the same failure mode of possible stack overflow.

    There's a choice of options in GCC to deal with stack protection.
Eg:  -fstack-check

    Plus a bunch of macros.

    They all deal with allocation of automatic variables. For alloca(),
instead, there's explicitely no check.

    In addition, the compiler is not informed of the invocation of
alloca(); therefore the space allocated to non-static automatic
variables may overlap with the space "allocated" by alloca().

>
> In any case, the implementation should put some limit on n before
> executing alloca() or int array[n].
>
> To be honest, I really don't seesomething against using alloca() despite
> its not Posix. Especially, there is no advantage of array[n] 
> regarding the stack overflow issue.
    See above.
>
> Of course, critical software should not rely on dynamic stack allocation
> since its unpredictable. (but also not on runtime heap allocation too)
    malloc() returns NULL il case of error. Errors should always be checked.


--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Steve Litt]

Bernard Rosset via Dng said on Wed, 21 Jul 2021 18:17:43 +0200

>>      I've found a discussion between a developper and Lennart
>> Poeterring in which LP recommends the addition of this kind of
>> functions in Musl libc (which will certainly never happen). It's
>> slightly amusing how the author of such a critical software as
>> systemd lacks a culture of security.  
>
>Many things he lacks if I would say.

There are people whose purpose and activity is sabotage. LP is one such
person.


SteveT

Steve Litt 
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Andreas Messer]

On Wed, Jul 21, 2021 at 02:36:16PM +0200, Didier Kryn wrote:
> added (by gcc ?) to work around a missing feature of the C language:
> dynamic allocation on the stack. This lack has disapeared many years ago
> ( don't know with which version of the C standard) , with the following
> form of allocation:
> 
> ...
> 
> n = 2x+1;
> 
> {
> 
>     int array[n];
> 
>     ...
> 
> }
> 
>     And, therefore, alloca() should be removed.

Well, alloca(n*sizeof(int)) and your suggestion both do the same in that 
they allocate memory from stack without any checking. Thus both will 
show the same failure mode of possible stack overflow.

In any case, the implementation should put some limit on n before
executing alloca() or int array[n].

To be honest, I really don't seesomething against using alloca() despite
its not Posix. Especially, there is no advantage of array[n] 
regarding the stack overflow issue.

Of course, critical software should not rely on dynamic stack allocation
since its unpredictable. (but also not on runtime heap allocation too)

cheers,
Andreas

-- 
gnuPG keyid: 8C2BAF51
fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51


signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Didier Kryn]

Le 21/07/2021 à 18:19, Tomasz Torcz a écrit :
> On Wed, Jul 21, 2021 at 06:00:15PM +0200, Didier Kryn wrote:
>> Le 21/07/2021 à 16:51, Bernard Rosset via Dng a écrit :
 https://www.zdnet.com/article/nasty-linux-systemd-security-bug-revealed/
>>> I'll be projecting myself here, but I reckon sharing the original
>>> source rather than journalistic articles whenever possible is best
>>> towards a tech-savvy audience.
>>>
>>> The source (included in above article) is here:
>>> https://blog.qualys.com/vulnerabilities-threat-research/2021/07/20/cve-2021-33910-denial-of-service-stack-exhaustion-in-systemd-pid-1
>>     The code shows the use of strdupa(). There is a family of functions
>> which are extensions of POSIX functions, with the suffix 'a' which
>> allocate space for the returned string from the stack. They are very
>> convenient for lazy programmer, but (slightly ?) dangerous and do not
>> belong to POSIX.
>>
>>     I've found a discussion between a developper and Lennart Poeterring
>> in which LP recommends the addition of this kind of functions in Musl
>> libc (which will certainly never happen). 
> That's amusing thought. strdupa() is in Musl:
> http://git.musl-libc.org/cgit/musl/tree/include/string.h#n89
> alloca() is there, too:
> http://git.musl-libc.org/cgit/musl/tree/include/alloca.h
>
    At least strdupa() is just a macro conditionned by #ifedf _GNU_SOURCE.

    Similarly alloca() is #defined as the compiler's built in alloca().

    This is a way to provide the minimal service to people wanting to
link with Musl programs developped for Glibc. I guess the pressure was
too high.

--     Didier





___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Tomasz Torcz]

On Wed, Jul 21, 2021 at 06:00:15PM +0200, Didier Kryn wrote:
> Le 21/07/2021 à 16:51, Bernard Rosset via Dng a écrit :
> >> https://www.zdnet.com/article/nasty-linux-systemd-security-bug-revealed/
> >
> > I'll be projecting myself here, but I reckon sharing the original
> > source rather than journalistic articles whenever possible is best
> > towards a tech-savvy audience.
> >
> > The source (included in above article) is here:
> > https://blog.qualys.com/vulnerabilities-threat-research/2021/07/20/cve-2021-33910-denial-of-service-stack-exhaustion-in-systemd-pid-1
> 
>     The code shows the use of strdupa(). There is a family of functions
> which are extensions of POSIX functions, with the suffix 'a' which
> allocate space for the returned string from the stack. They are very
> convenient for lazy programmer, but (slightly ?) dangerous and do not
> belong to POSIX.
> 
>     I've found a discussion between a developper and Lennart Poeterring
> in which LP recommends the addition of this kind of functions in Musl
> libc (which will certainly never happen). 

  That's amusing thought. strdupa() is in Musl:
http://git.musl-libc.org/cgit/musl/tree/include/string.h#n89
alloca() is there, too:
http://git.musl-libc.org/cgit/musl/tree/include/alloca.h


-- 
Tomasz Torcz  “If you try to upissue this patchset I shall be 
seeking
to...@pipebreaker.pl   an IP-routable hand grenade.”  — Andrew Morton (LKML)

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Bernard Rosset via Dng]

     I've found a discussion between a developper and Lennart Poeterring
in which LP recommends the addition of this kind of functions in Musl
libc (which will certainly never happen). It's slightly amusing how the
author of such a critical software as systemd lacks a culture of security.


Many things he lacks if I would say.

For CVE-2021-33910, maybe could we direct him towards a website to 
enlarge his culture?

Say... StackOverflow? Ba-dum-tss

Bernard (Beer) Rosset
https://rosset.net/
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Didier Kryn]

Le 21/07/2021 à 16:51, Bernard Rosset via Dng a écrit :
>> https://www.zdnet.com/article/nasty-linux-systemd-security-bug-revealed/
>
> I'll be projecting myself here, but I reckon sharing the original
> source rather than journalistic articles whenever possible is best
> towards a tech-savvy audience.
>
> The source (included in above article) is here:
> https://blog.qualys.com/vulnerabilities-threat-research/2021/07/20/cve-2021-33910-denial-of-service-stack-exhaustion-in-systemd-pid-1

    The code shows the use of strdupa(). There is a family of functions
which are extensions of POSIX functions, with the suffix 'a' which
allocate space for the returned string from the stack. They are very
convenient for lazy programmer, but (slightly ?) dangerous and do not
belong to POSIX.

    I've found a discussion between a developper and Lennart Poeterring
in which LP recommends the addition of this kind of functions in Musl
libc (which will certainly never happen). It's slightly amusing how the
author of such a critical software as systemd lacks a culture of security.

https://github.com/systemd/casync/issues/129


--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Bernard Rosset via Dng]

https://www.zdnet.com/article/nasty-linux-systemd-security-bug-revealed/


I'll be projecting myself here, but I reckon sharing the original source 
rather than journalistic articles whenever possible is best towards a 
tech-savvy audience.


The source (included in above article) is here: 
https://blog.qualys.com/vulnerabilities-threat-research/2021/07/20/cve-2021-33910-denial-of-service-stack-exhaustion-in-systemd-pid-1


That said, thanks for sharing!
Bernard (Beer) Rosset
https://rosset.net/
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Didier Kryn]

Le 21/07/2021 à 15:47, William Gallafent via Dng a écrit :
> According to a man page I happen to have in front of me, “alloca()
> appeared in Version 32V AT&T UNIX.”
>
> I've certainly seen it in use on code originally written during the
> last millennium for SGI IRIX, and then ported to several other
> systems, many years ago.
>
> It was C99 that introduced variable-length arrays, which is, as you
> say, also many years ago :)
>
> According to the same man page:
>
> ==B<==
> BUGS
>  alloca() is machine and compiler dependent; its use is discouraged.
>
>  alloca() is slightly unsafe because it cannot ensure that the
> pointer returned points to a valid and usable block of memory.  The
>  allocation made may exceed the bounds of the stack, or even go
> further into other objects in memory, and alloca() cannot determine
>  such an error.  Avoid alloca() with large unbounded allocations.
>
>  The use of C99 variable-length arrays and alloca() in the same
> function will cause the lifetime of alloca's storage to be limited
>  to the block containing the alloca()
> ==B<==
>
> Here endeth the lesson, certainly. I like the use of “slightly” in
> front of the word “unsafe”. Humorous.

    Slightly humorous (~:

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[William Gallafent via Dng]

On Wed, 21 Jul 2021 at 13:36, Didier Kryn  wrote:
> I want to add to the comments that this alloca() function has been
> added (by gcc ?) to work around a missing feature of the C language:
> dynamic allocation on the stack. This lack has disapeared many years ago
> ( don't know with which version of the C standard)
[…]

According to a man page I happen to have in front of me, “alloca()
appeared in Version 32V AT&T UNIX.”

I've certainly seen it in use on code originally written during the
last millennium for SGI IRIX, and then ported to several other
systems, many years ago.

It was C99 that introduced variable-length arrays, which is, as you
say, also many years ago :)

According to the same man page:

==B<==
BUGS
 alloca() is machine and compiler dependent; its use is discouraged.

 alloca() is slightly unsafe because it cannot ensure that the
pointer returned points to a valid and usable block of memory.  The
 allocation made may exceed the bounds of the stack, or even go
further into other objects in memory, and alloca() cannot determine
 such an error.  Avoid alloca() with large unbounded allocations.

 The use of C99 variable-length arrays and alloca() in the same
function will cause the lifetime of alloca's storage to be limited
 to the block containing the alloca()
==B<==

Here endeth the lesson, certainly. I like the use of “slightly” in
front of the word “unsafe”. Humorous.

The previous CVE from the same team is quite interesting too (and
looks unrelated to systemd, and will need to be fixed in Devuan
kernels).

https://blog.qualys.com/vulnerabilities-threat-research/2021/07/20/sequoia-a-local-privilege-escalation-vulnerability-in-linuxs-filesystem-layer-cve-2021-33909

-- 
Bill Gallafent.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Didier Kryn]

Le 20/07/2021 à 22:08, Dr. Nikolaus Klepp a écrit :
> Just in case sombody missed it:
>
> https://www.zdnet.com/article/nasty-linux-systemd-security-bug-revealed/
>
>
> "Systemd, the Linux system and service manager that has largely
> replaced init as the master Linux startup and control program, has
> always had its critics. Now, with Qualys's discovery of a new systemd
> security bug, systemd will have fewer friends. Successful exploitation
> of this newest vulnerability enables any unprivileged user to cause a
> denial of service via a kernel panic.
> In a phrase, "that's bad, that's really bad." [...]
> "
>
> Nik
>
    I want to add to the comments that this alloca() function has been
added (by gcc ?) to work around a missing feature of the C language:
dynamic allocation on the stack. This lack has disapeared many years ago
( don't know with which version of the C standard) , with the following
form of allocation:

...

n = 2x+1;

{

    int array[n];

    ...

}

    And, therefore, alloca() should be removed.

    delenda est alloca !

--     Didier




___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Steve Litt]

goli...@devuan.org said on Tue, 20 Jul 2021 16:20:33 -0500

>On 2021-07-20 15:52, Joel Roth via Dng wrote:
>> On Tue, Jul 20, 2021 at 10:08:48PM +0200, Dr. Nikolaus Klepp wrote:  

[snip]

>>> In a phrase, "that's bad, that's really bad."  
>> 
>> It seems that this is the tip of what will be be a very large
>> iceberg. 
>
>And Debian knows it.  They are starting to circle the wagons . . .

Zackly! Why reconsider your choices when you can just double down and
cal anybody who disagrees a stupid, change-phobic hater who doesn't
understand?

SteveT

Steve Litt 
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Steve Litt]

Dr. Nikolaus Klepp said on Tue, 20 Jul 2021 22:08:48 +0200

>Just in case sombody missed it:
>
>https://www.zdnet.com/article/nasty-linux-systemd-security-bug-revealed/

The exploit happens by mounting something to a very long path, crashing
systemd.

I'd like to remind everyone that the s6 init system, which is very
similar to runit, can handle a crash on its daemon supervisor, by
spawning another one. So even if s6 had the breathtaking attack surface
that systemd has, it still could not be exploited in this way.

SteveT

Steve Litt 
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[golinux]

On 2021-07-20 15:52, Joel Roth via Dng wrote:

On Tue, Jul 20, 2021 at 10:08:48PM +0200, Dr. Nikolaus Klepp wrote:

Just in case sombody missed it:

https://www.zdnet.com/article/nasty-linux-systemd-security-bug-revealed/


"Systemd, the Linux system and service manager that has largely 
replaced init as the master Linux startup and control program, has 
always had its critics. Now, with Qualys's discovery of a new systemd 
security bug, systemd will have fewer friends. Successful exploitation 
of this newest vulnerability enables any unprivileged user to cause a 
denial of service via a kernel panic.



In a phrase, "that's bad, that's really bad."


It seems that this is the tip of what will be be a very large iceberg.



And Debian knows it.  They are starting to circle the wagons . . .




[...]
"

Nik


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Joel Roth via Dng]

On Tue, Jul 20, 2021 at 10:08:48PM +0200, Dr. Nikolaus Klepp wrote:
> Just in case sombody missed it:
> 
> https://www.zdnet.com/article/nasty-linux-systemd-security-bug-revealed/
> 
> 
> "Systemd, the Linux system and service manager that has largely replaced init 
> as the master Linux startup and control program, has always had its critics. 
> Now, with Qualys's discovery of a new systemd security bug, systemd will have 
> fewer friends. Successful exploitation of this newest vulnerability enables 
> any unprivileged user to cause a denial of service via a kernel panic. 

> In a phrase, "that's bad, that's really bad." 

It seems that this is the tip of what will be be a very large iceberg. 


> [...]
> "
> 
> Nik
> 
> -- 
> Please do not email me anything that you are not comfortable also sharing 
> with the NSA, CIA ...
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

-- 
Joel Roth
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Nasty Linux systemd security bug revealed

[Dr. Nikolaus Klepp]

Just in case sombody missed it:

https://www.zdnet.com/article/nasty-linux-systemd-security-bug-revealed/


"Systemd, the Linux system and service manager that has largely replaced init 
as the master Linux startup and control program, has always had its critics. 
Now, with Qualys's discovery of a new systemd security bug, systemd will have 
fewer friends. Successful exploitation of this newest vulnerability enables any 
unprivileged user to cause a denial of service via a kernel panic. 

In a phrase, "that's bad, that's really bad." 
[...]
"

Nik

-- 
Please do not email me anything that you are not comfortable also sharing with 
the NSA, CIA ...
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng