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] Install OpenSSL (libssl, libcrypto) with weak ciphers

[aitor]

On 21/7/21 23:04, aitor wrote:

*libssl1.1* provides both libssl and libcrypto shared libraries.


Better said:

/usr/lib/x86_64-linux-gnu/libssl.so.1.1
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1

Aitor.


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

Re: [DNG] Install OpenSSL (libssl, libcrypto) with weak ciphers

[aitor]

Hi Mike,

On 21/7/21 15:20, Mike Tubby wrote:

Hi All,

I appear to have a problem with OpenSSL and lack of support for weak 
ciphers, i.e. DES and 3DES ...


I am trying to migrate a legacy system from Ubuntu 16.04 to Devuan 3.0 
where we have mobile IoT devices based on Cinterion TC65i that are 10+ 
years old with a limited sub-set of SSL 3.0/TLS 1.0 ciphers in its 
Java-ME runtime, in particular we need DES/3DESciphers like 
RSA-3DES-CBC-SHA


I have pulled the source package for openssl-1.1.1d and recompiled 
with configure option --enable-weak-ssl-ciphers that has  left we with 
a new libssl and a mixture of .deb files and .udeb files:


root@webmin1:/home/chris/openssl# ls -l
total 20364
-rw-r--r--  1 chris chris 1092008 Jul 21 13:41 
libcrypto1.1-udeb_1.1.1d-0+deb10u6_amd64.udeb
-rw-r--r--  1 chris chris 1539476 Jul 21 13:41 
libssl1.1_1.1.1d-0+deb10u6_amd64.deb
-rw-r--r--  1 chris chris 4024572 Jul 21 13:41 
libssl1.1-dbgsym_1.1.1d-0+deb10u6_amd64.deb
-rw-r--r--  1 chris chris  191008 Jul 21 13:41 
libssl1.1-udeb_1.1.1d-0+deb10u6_amd64.udeb
-rw-r--r--  1 chris chris 1794312 Jul 21 13:41 
libssl-dev_1.1.1d-0+deb10u6_amd64.deb
-rw-r--r--  1 chris chris 1722936 Jul 21 13:41 
libssl-doc_1.1.1d-0+deb10u6_all.deb

drwxr-xr-x 22 chris chris    4096 Jul 21 13:49 openssl-1.1.1d
-rw-r--r--  1 chris chris    6574 Jul 21 13:41 
openssl_1.1.1d-0+deb10u6_amd64.buildinfo
-rw-r--r--  1 chris chris    3724 Jul 21 13:41 
openssl_1.1.1d-0+deb10u6_amd64.changes
-rw-r--r--  1 chris chris  844036 Jul 21 13:41 
openssl_1.1.1d-0+deb10u6_amd64.deb
-rw-r--r--  1 root  root    99740 Mar 23 20:54 
openssl_1.1.1d-0+deb10u6.debian.tar.xz
-rw-r--r--  1 root  root 2472 Mar 23 20:54 
openssl_1.1.1d-0+deb10u6.dsc

drwxr-xr-x 20 root  root 4096 Jul 21 11:51 openssl-1.1.1d.orig
-rw-r--r--  1 root  root  8845861 Sep 14  2019 openssl_1.1.1d.orig.tar.gz
-rw-r--r--  1 root  root  488 Sep 14  2019 
openssl_1.1.1d.orig.tar.gz.asc
-rw-r--r--  1 chris chris  650980 Jul 21 13:41 
openssl-dbgsym_1.1.1d-0+deb10u6_amd64.deb

root@webmin1:/home/chris/openssl#

I don't appear to get a new 
libcrypto1.1-udeb_1.1.1d-0+deb10u6_amd64.deb but a udeb file instead 
that will not install.


What am I missing



*libssl1.1* provides both libssl and libcrypto shared libraries.

Cheers,

Aitor.


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

Re: [DNG] Install OpenSSL (libssl, libcrypto) with weak ciphers

[Gregory Nowak via Dng]

On Wed, Jul 21, 2021 at 02:20:50PM +0100, Mike Tubby wrote:
> I am trying to migrate a legacy system from Ubuntu 16.04 to Devuan 3.0 where
> we have mobile IoT devices based on Cinterion TC65i that are 10+ years old
> with a limited sub-set of SSL 3.0/TLS 1.0 ciphers in its Java-ME runtime, in
> particular we need DES/3DESciphers like RSA-3DES-CBC-SHA

There's an easier way. Just install the openssl packages already
provided in Devuan 3. Edit /etc/ssl/openssl.cnf, and change the last
line from:

CipherString = DEFAULT@SECLEVEL=2

to:

CipherString = DEFAULT@SECLEVEL=1

This will weaken the security of your ssl connections, but it sounds
like you are already prepared to accept that risk.

Greg


-- 
web site: http://www.gregn.net
gpg public key: http://www.gregn.net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)
If we haven't been in touch before, e-mail me before adding me to your contacts.

--
Free domains: http://www.eu.org/ or mail dns-mana...@eu.org
___
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] RFC: minimal-live iso changes for chimaera

[Bernard Rosset via Dng]

I've used transmission in the past but currently use deluge. Both have
a gui, whereas AFAIR them as relatively klunky.  YMMV.


I have been a user of Transmission for years, because license, features 
and history talk for it.
I just checked Deluge on those and it seems decent too (despite the fact 
there is apparently some Python bake into).


IIRC, both use a client-server model. It is great on a server, but I 
guess the idea of the minimal-live is to server as a showcase/demo 
instance on a user-facing machine.

Isn't a standalone "hard" client what is sought there?

If those are the only options, then Transmission might have a killing 
feature: on top of the remote cli client, there also is an integrated 
Web GUI available on the daemon: really handy, at no extra cost.


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 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 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

[DNG] Install OpenSSL (libssl, libcrypto) with weak ciphers

[Mike Tubby]

Hi All,

I appear to have a problem with OpenSSL and lack of support for weak 
ciphers, i.e. DES and 3DES ...


I am trying to migrate a legacy system from Ubuntu 16.04 to Devuan 3.0 
where we have mobile IoT devices based on Cinterion TC65i that are 10+ 
years old with a limited sub-set of SSL 3.0/TLS 1.0 ciphers in its 
Java-ME runtime, in particular we need DES/3DESciphers like RSA-3DES-CBC-SHA


I have pulled the source package for openssl-1.1.1d and recompiled with 
configure option --enable-weak-ssl-ciphers that has  left we with a new 
libssl and a mixture of .deb files and .udeb files:


root@webmin1:/home/chris/openssl# ls -l
total 20364
-rw-r--r--  1 chris chris 1092008 Jul 21 13:41 
libcrypto1.1-udeb_1.1.1d-0+deb10u6_amd64.udeb
-rw-r--r--  1 chris chris 1539476 Jul 21 13:41 
libssl1.1_1.1.1d-0+deb10u6_amd64.deb
-rw-r--r--  1 chris chris 4024572 Jul 21 13:41 
libssl1.1-dbgsym_1.1.1d-0+deb10u6_amd64.deb
-rw-r--r--  1 chris chris  191008 Jul 21 13:41 
libssl1.1-udeb_1.1.1d-0+deb10u6_amd64.udeb
-rw-r--r--  1 chris chris 1794312 Jul 21 13:41 
libssl-dev_1.1.1d-0+deb10u6_amd64.deb
-rw-r--r--  1 chris chris 1722936 Jul 21 13:41 
libssl-doc_1.1.1d-0+deb10u6_all.deb

drwxr-xr-x 22 chris chris    4096 Jul 21 13:49 openssl-1.1.1d
-rw-r--r--  1 chris chris    6574 Jul 21 13:41 
openssl_1.1.1d-0+deb10u6_amd64.buildinfo
-rw-r--r--  1 chris chris    3724 Jul 21 13:41 
openssl_1.1.1d-0+deb10u6_amd64.changes
-rw-r--r--  1 chris chris  844036 Jul 21 13:41 
openssl_1.1.1d-0+deb10u6_amd64.deb
-rw-r--r--  1 root  root    99740 Mar 23 20:54 
openssl_1.1.1d-0+deb10u6.debian.tar.xz

-rw-r--r--  1 root  root 2472 Mar 23 20:54 openssl_1.1.1d-0+deb10u6.dsc
drwxr-xr-x 20 root  root 4096 Jul 21 11:51 openssl-1.1.1d.orig
-rw-r--r--  1 root  root  8845861 Sep 14  2019 openssl_1.1.1d.orig.tar.gz
-rw-r--r--  1 root  root  488 Sep 14  2019 
openssl_1.1.1d.orig.tar.gz.asc
-rw-r--r--  1 chris chris  650980 Jul 21 13:41 
openssl-dbgsym_1.1.1d-0+deb10u6_amd64.deb

root@webmin1:/home/chris/openssl#

I don't appear to get a new libcrypto1.1-udeb_1.1.1d-0+deb10u6_amd64.deb 
but a udeb file instead that will not install.


What am I missing?


Mike
___
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] New service manager being developed

[d...@d404.nl]

On 20-07-2021 22:33, Martin Steigerwald wrote:

Hi!

Look at

https://skarnet.com/projects/service-manager.html

Sounds quite interesting, if you ask me.

Best,


Great initiative. I am currently using Alpine combined with s6-overlay 
in most of my docker containers and it works very well.


A separate initiative to write more readable documentation for the 
masses would surely help to get more traction.


Grtz.

Nick





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