from:"Elmar Stellnberger"

  Just make sure you comment out the tests. It will greatly speed up 
compilation and one of these tests was even hanging two times:

./a.out -test.short -test.timeout=240s

  It is a known Debian Bug that the Go tests (a programming language) 
fail with with gcc-8. If not you would have to connect with gdb to the 
make process, attach to its pid and close file descriptor three to 
continue. Nonetheless the necessary packages listed in my last email get 
created before that.

On 17.04.22 18:06, Elmar Stellnberger wrote:
Likely it is possible to comment out the tournament checks after 
compilation (which did not succeed to find this error any way) in 
debian/rules; I would do it like this:

check:

check22: $(check_stamp)
$(check_stamp): $(build_stamp)
 $(MAKE) -f debian/rules2 $@

(here I have renamed check into check22 and created a new empty check goal)
That should save 80% of the compilation time.

Elmar

On 17.04.22 17:46, Elmar Stellnberger wrote:
   I have now downloaded the source package and examined the backtrace 
of building Firefox and examined all the differences between gcc 
8.3.0-1 (known bad from Debian10) and gcc 9.2.0 with gcc 9.2.1 being 
known to be good for moc/Qt5 from Ubuntu 19.10. There was only one 
difference I found along the backtrace for gcc and I have documented 
this in the following gcc/g++ bug report. You can also download the 
patch from here:

   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105293

I have rebuilt with the posted patch and the output has shown me that 
all package files must have been created successfully:

Build Dependencies:
Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend 

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version    Architecture 
Description
+++-=-==--=== 

ii  binutils  2.31.1-16  i386 GNU 
assembler, linker and binary utilities
ii  binutils-common:i386  2.31.1-16  i386 
Common files for the GNU assembler, linker and binary utilities
ii  binutils-hppa64-linux-gnu 2.31.1-16  i386 GNU 
assembler, linker and binary utilities targeted for hppa64-linux
ii  binutils-i686-linux-gnu   2.31.1-16  i386 GNU 
binary utilities, for i686-linux-gnu target
ii  g++-8 8.3.0-6    i386 GNU 
C++ compiler
ii  g++-8-dbgsym  8.3.0-6    i386 
debug symbols for g++-8
ii  g++-8-multilib    8.3.0-6    i386 GNU 
C++ compiler (multilib support)
ii  g++-multilib  4:8.3.0-1  i386 GNU 
C++ compiler (multilib files)
ii  libc6:i386    2.28-10+deb10u1    i386 GNU 
C Library: Shared libraries
ii  libgmp-dev:i386   2:6.1.2+dfsg-4+deb10u1 i386 
Multiprecision arithmetic library developers tools
ii  libisl-dev:i386   0.20-2 i386 manipulating 
sets and relations of integer points bounded by linear constraints
ii  libmpc-dev:i386   1.1.0-1    i386 multiple 
precision complex floating-point library development package
ii  libmpfr-dev:i386  4.0.2-1    i386 multiple 
precision floating-point computation developers tools

(from gcc-bug:, this is terror by Western secret services, as also 
referenced by elstel.org/DualSat) "I have looked into the same 
directory as before but unfortunately I found not a single .deb there 
and nowhere else under /usr/src. The files can only have been deleted 
like the ssh user from /etc/passwd at my nslu2 machine. Another time I 
found out about a chmod -x /etc/init.d/sshd as I suddenly could not 
connect to my nslu2 via ssh any more. This looks very similar as what 
I have experienced with arm-linux-gnueabihf-ld when the program did 
neither produce an error message, an !=0 return value and no output 
file as given with -o txtfmt."
   If you know programs like gcc or the linker ld, then you know they 
will always produce an error message if something fails. Even if there 
was a bug in ld to display no error it would have returned a non-zero 
exit status. Anyone who has worked with tools like gcc or ld/collect2 
knows that. I have really searched for a txtfmt/a.out everywhere 
possible.

   I am quite sure that the posted patch would resolve the issue. I 
would appreciate it very much if someone was ready to compile that 
with a Debian10/i386 chroot:

as root:
  > debootstrap --arch i386 buster /dst/dbuster-i386
  > xchroot /dst/dbuster-i386
  > ... install build-essential apt-src locales-all etc.
  > cd /usr/src
  > apt-src update
  > apt-src install gcc-8

Compiling may need more than a day; however you may hibernate in 
betwee

Re: [SECURITY] [DSA 5113-1] firefox-esr security update

Likely it is possible to comment out the tournament checks after 
compilation (which did not succeed to find this error any way) in 
debian/rules; I would do it like this:

check:

check22: $(check_stamp)
$(check_stamp): $(build_stamp)
$(MAKE) -f debian/rules2 $@

(here I have renamed check into check22 and created a new empty check goal)
That should save 80% of the compilation time.

Elmar

On 17.04.22 17:46, Elmar Stellnberger wrote:
   I have now downloaded the source package and examined the backtrace 
of building Firefox and examined all the differences between gcc 8.3.0-1 
(known bad from Debian10) and gcc 9.2.0 with gcc 9.2.1 being known to be 
good for moc/Qt5 from Ubuntu 19.10. There was only one difference I 
found along the backtrace for gcc and I have documented this in the 
following gcc/g++ bug report. You can also download the patch from here:

   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105293

I have rebuilt with the posted patch and the output has shown me that 
all package files must have been created successfully:

Build Dependencies:
Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend 

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version    Architecture 
Description
+++-=-==--=== 

ii  binutils  2.31.1-16  i386 GNU 
assembler, linker and binary utilities
ii  binutils-common:i386  2.31.1-16  i386 Common 
files for the GNU assembler, linker and binary utilities
ii  binutils-hppa64-linux-gnu 2.31.1-16  i386 GNU 
assembler, linker and binary utilities targeted for hppa64-linux
ii  binutils-i686-linux-gnu   2.31.1-16  i386 GNU 
binary utilities, for i686-linux-gnu target
ii  g++-8 8.3.0-6    i386 GNU 
C++ compiler
ii  g++-8-dbgsym  8.3.0-6    i386 debug 
symbols for g++-8
ii  g++-8-multilib    8.3.0-6    i386 GNU 
C++ compiler (multilib support)
ii  g++-multilib  4:8.3.0-1  i386 GNU 
C++ compiler (multilib files)
ii  libc6:i386    2.28-10+deb10u1    i386 GNU C 
Library: Shared libraries
ii  libgmp-dev:i386   2:6.1.2+dfsg-4+deb10u1 i386 Multiprecision 
arithmetic library developers tools
ii  libisl-dev:i386   0.20-2 i386 manipulating 
sets and relations of integer points bounded by linear constraints
ii  libmpc-dev:i386   1.1.0-1    i386 multiple 
precision complex floating-point library development package
ii  libmpfr-dev:i386  4.0.2-1    i386 multiple 
precision floating-point computation developers tools

(from gcc-bug:, this is terror by Western secret services, as also 
referenced by elstel.org/DualSat) "I have looked into the same directory 
as before but unfortunately I found not a single .deb there and nowhere 
else under /usr/src. The files can only have been deleted like the ssh 
user from /etc/passwd at my nslu2 machine. Another time I found out 
about a chmod -x /etc/init.d/sshd as I suddenly could not connect to my 
nslu2 via ssh any more. This looks very similar as what I have 
experienced with arm-linux-gnueabihf-ld when the program did neither 
produce an error message, an !=0 return value and no output file as 
given with -o txtfmt."
   If you know programs like gcc or the linker ld, then you know they 
will always produce an error message if something fails. Even if there 
was a bug in ld to display no error it would have returned a non-zero 
exit status. Anyone who has worked with tools like gcc or ld/collect2 
knows that. I have really searched for a txtfmt/a.out everywhere possible.

   I am quite sure that the posted patch would resolve the issue. I 
would appreciate it very much if someone was ready to compile that with 
a Debian10/i386 chroot:

as root:
  > debootstrap --arch i386 buster /dst/dbuster-i386
  > xchroot /dst/dbuster-i386
  > ... install build-essential apt-src locales-all etc.
  > cd /usr/src
  > apt-src update
  > apt-src install gcc-8

Compiling may need more than a day; however you may hibernate in 
between. Make sure you have copied the patch into 
gcc-8-8.3.0/debian/patches/ and check that file has been patched some 
good minutes after compilation has started:

grep "chkp_reset_rtl_bounds ();" gcc-8-8.3.0/src/gcc/cfgexpand.c || echo ok

before it should not echo ok but the line with chkp_reset_rtl_bounds

invoke the build inside the gcc-8-8.3.0 directory:
   dpkg-buildpackage -b -uc -us [-nc] 2>&1 | tee compile-gcc.msg
// -b ... build binary
// -uc -us ... do not sign (I use -kestel...@elstel.org, se

Re: [SECURITY] [DSA 5113-1] firefox-esr security update

  I have now downloaded the source package and examined the backtrace 
of building Firefox and examined all the differences between gcc 8.3.0-1 
(known bad from Debian10) and gcc 9.2.0 with gcc 9.2.1 being known to be 
good for moc/Qt5 from Ubuntu 19.10. There was only one difference I 
found along the backtrace for gcc and I have documented this in the 
following gcc/g++ bug report. You can also download the patch from here:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105293

I have rebuilt with the posted patch and the output has shown me that 
all package files must have been created successfully:


Build Dependencies:
Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  VersionArchitecture 
Description

+++-=-==--===
ii  binutils  2.31.1-16  i386 GNU 
assembler, linker and binary utilities
ii  binutils-common:i386  2.31.1-16  i386 Common 
files for the GNU assembler, linker and binary utilities
ii  binutils-hppa64-linux-gnu 2.31.1-16  i386 GNU 
assembler, linker and binary utilities targeted for hppa64-linux
ii  binutils-i686-linux-gnu   2.31.1-16  i386 GNU 
binary utilities, for i686-linux-gnu target
ii  g++-8 8.3.0-6i386 GNU 
C++ compiler
ii  g++-8-dbgsym  8.3.0-6i386 debug 
symbols for g++-8
ii  g++-8-multilib8.3.0-6i386 GNU 
C++ compiler (multilib support)
ii  g++-multilib  4:8.3.0-1  i386 GNU 
C++ compiler (multilib files)
ii  libc6:i3862.28-10+deb10u1i386 GNU C 
Library: Shared libraries
ii  libgmp-dev:i386   2:6.1.2+dfsg-4+deb10u1 i386 
Multiprecision arithmetic library developers tools
ii  libisl-dev:i386   0.20-2 i386 
manipulating sets and relations of integer points bounded by linear 
constraints
ii  libmpc-dev:i386   1.1.0-1i386 
multiple precision complex floating-point library development package
ii  libmpfr-dev:i386  4.0.2-1i386 
multiple precision floating-point computation developers tools



(from gcc-bug:, this is terror by Western secret services, as also 
referenced by elstel.org/DualSat) "I have looked into the same directory 
as before but unfortunately I found not a single .deb there and nowhere 
else under /usr/src. The files can only have been deleted like the ssh 
user from /etc/passwd at my nslu2 machine. Another time I found out 
about a chmod -x /etc/init.d/sshd as I suddenly could not connect to my 
nslu2 via ssh any more. This looks very similar as what I have 
experienced with arm-linux-gnueabihf-ld when the program did neither 
produce an error message, an !=0 return value and no output file as 
given with -o txtfmt."
  If you know programs like gcc or the linker ld, then you know they 
will always produce an error message if something fails. Even if there 
was a bug in ld to display no error it would have returned a non-zero 
exit status. Anyone who has worked with tools like gcc or ld/collect2 
knows that. I have really searched for a txtfmt/a.out everywhere possible.


  I am quite sure that the posted patch would resolve the issue. I 
would appreciate it very much if someone was ready to compile that with 
a Debian10/i386 chroot:


as root:
 > debootstrap --arch i386 buster /dst/dbuster-i386
 > xchroot /dst/dbuster-i386
 > ... install build-essential apt-src locales-all etc.
 > cd /usr/src
 > apt-src update
 > apt-src install gcc-8

Compiling may need more than a day; however you may hibernate in 
between. Make sure you have copied the patch into 
gcc-8-8.3.0/debian/patches/ and check that file has been patched some 
good minutes after compilation has started:


grep "chkp_reset_rtl_bounds ();" gcc-8-8.3.0/src/gcc/cfgexpand.c || echo ok

before it should not echo ok but the line with chkp_reset_rtl_bounds

invoke the build inside the gcc-8-8.3.0 directory:
  dpkg-buildpackage -b -uc -us [-nc] 2>&1 | tee compile-gcc.msg
// -b ... build binary
// -uc -us ... do not sign (I use -kestel...@elstel.org, see gpg 
--list-keys)


  You can stop as soon as it has created the .deb packages. Grep for a 
line like "ii.*libgmp-dev:i386" in compile-gcc.msg to find that out. Do 
not forget to shield the + characters of g++ i.e. grep "g[+][+]-8-multilib "


  It will be of great help if anyone decides to do so!
Remember it should resolve several dependent bugs in Buster/i586 and 
also distributions of similar time.


Regards,
Elmar




On 16.04.22 17:20, Odo

Re: amd64 running on Intel Celeron and Pentium?

I haven´t heard yet of a Pentium IV supporting amd64.
Likely it does not exist.

On Sun, Apr 17, 2022 at 10:05:39AM +0200, Friedhelm Waitzmann wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> piorunz:
> > On 12/04/2022 04:59, Friedhelm Waitzmann wrote:
> > > You mean, that it is possible to run amd64 on my old hardware
> > > 
> > > 
> > > 1#
> > > 
> > > vendor_id   : GenuineIntel
> > > cpu family  : 6
> > > model   : 22
> > > model name  : Intel(R) Celeron(R) CPU  440  @ 2.00GHz
> > > stepping    : 1
> > > microcode   : 0x43
> > > cpu MHz : 1229.629
> > > cache size  : 512 KB
> > > 
> > > and
> > > 
> > > 2#
> > > 
> > > vendor_id   : GenuineIntel
> > > cpu family  : 15
> > > model   : 2
> > > model name  : Intel(R) Pentium(R) 4 CPU 2.00GHz
> > > stepping    : 4
> > > cpu MHz : 1993.656
> > > cache size  : 512 KB
> > > 
> > > ?
> 
> > Celeron 440 for sure is 64-bit. Pentium 4 2.00 GHz I am not sure, there
> > are many models and variations of this processor. Is it socket LGA775
> > also?
> 
> It is a Willamette on a socket 423.
> 
> 
> 
> Friedhelm
> -BEGIN PGP SIGNATURE-
> 
> iQFOBAEBCgA4FiEEzf8af16GP0HJOpBzgEIvCiHZTesFAmJbyJUaHGZhY2gyMjA0
> MDguZnduc3BAeG94eS5uZXQACgkQgEIvCiHZTevUVQgAr6A6NmLgghgCeMuahMxK
> aH5qzjteq8ZqinBpV2OWo9K4XkMkYXG/1YUfa0Ky9a+XGNP0EVyWjubcbxYCLxsH
> iuD7gh7Om7Iim93cNF51wJwn6zJMraOua4ke0XAngX+LID4Fxkj3eAGqAZqEJDAr
> dV7aj2SSZ+5i/u0KaEDP8uozcBx34fcxlayIMiTTm1odNgRIyFutOcLu55KQs30c
> VGxb5M/T98UJVRwhABpVD4jlKnesjExJO4tmvxG7xGuC1qxz3OBAEzECoerhd0sD
> NVoOOb0ARgn1pyPNo+YTcGSQxUDV8bZhZSR38i7zXYf3nH24MpSgnEW759w92MCc
> 1w==
> =UEtL
> -END PGP SIGNATURE-
>

Re: [SECURITY] [DSA 5113-1] firefox-esr security update

2022-04-16 Thread Elmar Stellnberger

  Maybe the Qt/moc and the gcc/Firefox bugs are unrelated. I
have not heard anything about it here yet. I have found a page
that tells the moc error can be resolved by upgrading from Qt
5.4.1 -> 5.4.2.

https://topic.alibabacloud.com/a/usrincludec641bitsstl_relops67parse-error-at-std_1_31_30235235.html

  It would be a general question of mine regarding both bugs why
you do not simply up/downgrade to the last known good version.
The i386 target would work well including the required security
updates and it would not be necessary to develop a patch for
these issues.
  Given that this should not be possible for some reason, please
share your knowledge about these bugs, so that people like me
can try to find a fix.

Elmar

On Fri, Apr 15, 2022 at 06:37:33PM +0200, Elmar Stellnberger wrote:
> On Fri, Apr 15, 2022 at 04:52:55PM +0200, Elmar Stellnberger wrote:
> > ...
> > exist. It truely is this g++ bug that prevents Firefox and any
> > Qt programs from building under Buster/i586. I have noted that
> > there are also some amd64 targets on the OBS that expose the
> > exact same g++ bug. My question would be on why the fixup/patch
> > from amd64 can not be used for g++/i386 on Debian?
> 
>   May I see what has fixed the issue for amd64 on Debian10 /
> Buster? That may greatly facilitate the development for a patch
> on i386. I believe the issue should really be fixed.
> 
> Elmar
>

Re: [SECURITY] [DSA 5113-1] firefox-esr security update

2022-04-15 Thread Elmar Stellnberger

On Fri, Apr 15, 2022 at 04:52:55PM +0200, Elmar Stellnberger wrote:
> ...
> exist. It truely is this g++ bug that prevents Firefox and any
> Qt programs from building under Buster/i586. I have noted that
> there are also some amd64 targets on the OBS that expose the
> exact same g++ bug. My question would be on why the fixup/patch
> from amd64 can not be used for g++/i386 on Debian?

  May I see what has fixed the issue for amd64 on Debian10 /
Buster? That may greatly facilitate the development for a patch
on i386. I believe the issue should really be fixed.

Elmar

Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)

2022-04-15 Thread Elmar Stellnberger


On 14.04.22 15:45, Levis Yarema wrote:

Is there in deed any reason to prefer amd64 over i586 if you have the
choice and a machine with 2GB RAM or less, apart from perhaps long term
support?



  Depends on the application. Encryption and decryption
requiring the simulation of very larger integers shall be faster
when being based on 64bit integers. However these are rather
special purposes.
  CPU and memory intense applications like the SAT-solver I am
developing on the other hand will be faster on i386 since a
memory reference/ pointer only requires 4 byte instead of 8
byte. Smaller size will yield less memory access cycles and more
cache hits and that can make an application considerably faster.
It is the cache that is effectively more important than the
register layout. Some SAT-solvers like f.i. the DNNF-c2d are
only available for Linux/i386, not for amd64.
  Concerning general purpose applications normal integers keep
to be 32bit even on amd64. Note the sizeof(int). This is also
for the rationale described above. x86_32 programs can even be
smaller on disk and in memory. I personally don´t think that
there is much reason to use amd64 with 2GB ram or less, except
for bigint calculations.
  Note however that with a 64bit kernel you can execute programs
in a 64bit and 32bit chroot while this is impossible with a
32bit kernel. This is a reason why many people boot with a 64bit
kernel but use a 32bit installation. As for certain CPU and
memory intense programs you can run them as i386 binary even on
an x86_64 root given that i386 system libararies are installed
which is possible with dpkg --add-architecture i386.

Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)

2022-04-15 Thread Elmar Stellnberger


On 15.04.22 04:50, Lennart Sorensen wrote:

On Thu, Apr 14, 2022 at 03:45:37PM +0200, Levis Yarema wrote:

Is there in deed any reason to prefer amd64 over i586 if you have the
choice and a machine with 2GB RAM or less, apart from perhaps long term
support?


Twice the registers and sse instructions for fpu rather than x87?



  That is not correct. You can make use of SSE instructions also in 
x86_32/i386 mode.


I found f.i.:
https://gcc.gcc.gnu.narkive.com/k0KqaZF2/i386-sse-test-question

Re: [SECURITY] [DSA 5113-1] firefox-esr security update

On 14.04.22 14:52, Elmar Stellnberger wrote:

   I am also running Debian 10 on my Asus eeePC (Pentium M). I
am mainly using it as a dictionary. Although I am performing
security updates quite regularly I have not run into this
issue. Having updated just now I am with Firefox
78.15.0-esr-1~deb10u1 and with

** gcc 4:8.3.0-1 being offered by

  I have looked at the build log of QCoan in the OBS and it is using
gcc-8-8.3.0-6. That is even newer than what got installed by the 
updates. I would thus believe that the gcc bug is still there that 
prevents some Firefox version from building, but that I simply have not 
noticed this issue via the normal upgrade process.

  Another explanation would of course be that the two errors are unrelated.

> Where can I get this from for buster and architecture i386?
> 
<http://security.debian.org/debian-security/dists/buster/updates/main/binary-i386/Packages.xz> 

> does not have it.

  Friedhelm, how have you taken notice about this issue?
Was the file really not there or do you think you have forgotten to type 
firefox-esr instead of firefox or something the like?

> Package: firefox-esr
> CVE ID : CVE-2022-1097  CVE-2022-1196  CVE-2022-24713 
CVE-2022-28281
>   CVE-2022-28282 CVE-2022-28285 CVE-2022-28286 
CVE-2022-28289

>
> Multiple security issues have been found in the Mozilla Firefox web
> browser, which could potentially result in the execution of arbitrary
> code, information disclosure or spoofing.
>
> For the oldstable distribution (buster), these problems have been fixed
> in version 91.8.0esr-1~deb10u1.
>
> For the stable distribution (bullseye), these problems have been fixed in
> version 91.8.0esr-1~deb11u1.
>
> We recommend that you upgrade your firefox-esr packages.

 At me it apparently has really kept an old unfixed version.
The message says fixed for oldstable, not mentioning that the fix has 
not yet been achieved for i386 and that it was only applied to amd64.

Re: [SECURITY] [DSA 5113-1] firefox-esr security update

On Thu, Apr 14, 2022 at 02:50:32PM +0200, Elmar Stellnberger wrote:
> On Sat, Apr 09, 2022 at 11:31:01PM +0200, Moritz Mühlenhoff wrote:
> > Friedhelm Waitzmann wrote:
> > >> For the oldstable distribution (buster), these problems have 
> > >> been fixed in version 91.8.0esr-1~deb10u1.
> > >
> > >  Where can I get this from for buster and architecture i386?  
> > > <http://security.debian.org/debian-security/dists/buster/updates/main/binary-i386/Packages.xz>
> > >  
> > >  does not have it.
> > 
> > The Firefox ESR91 series triggers an internal compiler error
> > with the GCC version included in Debian 10, so there's no build
> > available currently.
> 
>   I am also running Debian 10 on my Asus eeePC (Pentium M). I 
> am mainly using it as a dictionary. Although I am performing
> security updates quite regularely I have not run into this
> issue. Having updated just now I am with Firefox
> 78.15.0-esr-1~deb10u1 and with 
** 4:8.3.0-1 being offered by

- I mean the gcc version

> apt-cache.
>   Have I missed something or is the problem already resolved?
> 

Firefox works good on it like always.

Re: [SECURITY] [DSA 5113-1] firefox-esr security update

On Sat, Apr 09, 2022 at 11:31:01PM +0200, Moritz Mühlenhoff wrote:
> Friedhelm Waitzmann wrote:
> >> For the oldstable distribution (buster), these problems have 
> >> been fixed in version 91.8.0esr-1~deb10u1.
> >
> >  Where can I get this from for buster and architecture i386?  
> > 
> >  
> >  does not have it.
> 
> The Firefox ESR91 series triggers an internal compiler error
> with the GCC version included in Debian 10, so there's no build
> available currently.

  I am also running Debian 10 on my Asus eeePC (Pentium M). I 
am mainly using it as a dictionary. Although I am performing
security updates quite regularely I have not run into this
issue. Having updated just now I am with Firefox
78.15.0-esr-1~deb10u1 and with 4:8.3.0-1 being offered by
apt-cache.
  Have I missed something or is the problem already resolved?

Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)

On Wed, Apr 13, 2022 at 03:11:04PM -0400, Michael Stone wrote:
> On Wed, Apr 13, 2022 at 08:18:30PM +0200, Levis Yarema wrote:
> > What about Spectre /Meltdown? P3/P4/Pentium M systems don´t have that? Core 
> > 2
> > systems to my knowledge can.
> 
> There's no reason to believe netburst systems are not affected by any of the
> cpu issues identified in the past few years, but they are obsolete and
> unsupported so nobody is making official statements about them. These
> systems also lack a number of security features present in modern CPUs;
> picking an ancient chip for "security reasons" is likely misguided. Also, in
> the context of this thread, note that the most recent Core 2 processor was
> released in 2010.
> 

  AFAIK there is just no official statement of Intel about Pentium
III, IV and M CPUs. That may also be because they want(ed) people
to buy newer machines. Nonetheless I would be in wonder if
nobody at all had ever tested these CPUs for Spectre and
Meltdown. The issue itself wasn´t discovered by Intel either.

Elmar

Re: [SECURITY] [DSA 5113-1] firefox-esr security update

On Thu, Apr 14, 2022 at 11:01:06AM +0200, Maurice Dirr wrote:
> Are you running KDE programs on a Pentium 4?
> How can that work without hardware acceleration?
>  

  Well QCoan is a plain Qt program, not a KDE app, but Yes I am
running KDE apps on that PIV. You have to use
> export LIBGL_ALWAYS_SOFTWARE=1

  I have put that at the beginning into my /etc/lxdm/Xsession,
so that I do not always have to start from console exporting an
environment variable. I want to access these apps from the start
menu of the GUI and thus the variable needs to be defined for
the whole X-session.

> On 14.04.22 10:52, Elmar Stellnberger wrote:
> >Could it be that also other programs are affected by this issue?
> > > I have been building Coan (one of my programs) recently on the OBS and it
> > > did not build on Debian10/i586 giving an error at /usr/lib/qt5/bin/moc. 
> > > The
> > > amd64 target did build well. Since all reasonable Qt programs use moc 
> > > (Qt´s
> > > meta object compiler, see: signals) that would then mean that none of the 
> > > Qt
> > > programs would build. Can that be true?
> > >
> >
> > I am still using Mageia 7 on an old PIV of mine and it has a
> > similar gcc. Neither does there appear to be a problem with
> > Firefox. Anyone knows if the same issue appears with other
> > distros as well?

Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)


On 14.04.22 10:37, Paul Wise wrote:

On Tue, 2022-04-12 at 05:59 +0200, Friedhelm Waitzmann wrote:


And if it is indeed possible, how can I switch from i386 to
amd64?  Can this be done with the apt tools?  Then during the
migrating some packages will be from amd64 already while others
will be still i386.  How does that go right?


If your hardware supports it, you can either reinstall from scratch or
cross-grade an existing install from i386 to amd64, either using the
crossgrader tool or more manual methods of doing the same thing.

https://packages.debian.org/crossgrader
https://wiki.debian.org/CrossGrading



  If I had to do it, I would just upgrade to Debian 11. It is most easy 
 to do and you do not need things like a crossgrader tool. Though the 
procedure seems somewhat difficult to me, it is interesting to know that 
something like crossgrading exists and where you find documentation 
about it.

Re: [SECURITY] [DSA 5113-1] firefox-esr security update

2022-04-13 Thread Elmar Stellnberger

On Wed, Apr 13, 2022 at 09:52:13PM +0200, Elmar Stellnberger wrote:
> On 09.04.22 23:31, Moritz Mühlenhoff wrote:
> > Friedhelm Waitzmann wrote:
> >>> For the oldstable distribution (buster), these problems have
> >>> been fixed in version 91.8.0esr-1~deb10u1.
> >>
> >>  Where can I get this from for buster and architecture i386?
> >> <http://security.debian.org/debian-security/dists/buster/updates/main/binary-i386/Packages.xz>
> 
> >>  does not have it.
> >
> > The Firefox ESR91 series triggers an internal compiler error
> > with the GCC version included in Debian 10, so there's no build
> > available currently.
> >
> > There's one for Debian 11 (where GCC builds it correctly), but
> > I'd instead suggest to switch to amd64 instead.
> >
> > Cheers,
> > Moritz
> >
> 
>   Could it be that also other programs are affected by this issue?
> I have been building Coan (one of my programs) recently on the OBS and it
> did not build on Debian10/i586 giving an error at /usr/lib/qt5/bin/moc. The
> amd64 target did build well. Since all reasonable Qt programs use moc (Qt´s
> meta object compiler, see: signals) that would then mean that none of the Qt
> programs would build. Can that be true?
> 

  I am still using Mageia 7 on an old PIV of mine and it has a
similar gcc. Neither does there appear to be a problem with
Firefox. Anyone knows if the same issue appears with other
distros as well?

Deb 11: gcc 10.2.1-1
Deb 10: gcc 8.3.0-1
Mg 7:   gcc-8.4.0-1

Deb10: firefox 91.8.0esr-1
Mg 7:  firefox 78.11.0-1

P.S.:
  The moc error message I get with Debian 10 for Coan is the following:
[  244s] usr/include/c++/8/bits/stl_relops.:67: Parse error at "std"

Re: [SECURITY] [DSA 5113-1] firefox-esr security update

2022-04-13 Thread Elmar Stellnberger

On 09.04.22 23:31, Moritz Mühlenhoff wrote:
> Friedhelm Waitzmann wrote:
>>> For the oldstable distribution (buster), these problems have
>>> been fixed in version 91.8.0esr-1~deb10u1.
>>
>>  Where can I get this from for buster and architecture i386?
>> 

>>  does not have it.
>
> The Firefox ESR91 series triggers an internal compiler error
> with the GCC version included in Debian 10, so there's no build
> available currently.
>
> There's one for Debian 11 (where GCC builds it correctly), but
> I'd instead suggest to switch to amd64 instead.
>
> Cheers,
> Moritz
>

  Could it be that also other programs are affected by this issue?
I have been building Coan (one of my programs) recently on the OBS and 
it did not build on Debian10/i586 giving an error at 
/usr/lib/qt5/bin/moc. The amd64 target did build well. Since all 
reasonable Qt programs use moc (Qt´s meta object compiler, see: signals) 
that would then mean that none of the Qt programs would build. Can that 
be true?

Re: rkhunter finds something suspicious

  You should execute the commands below when you install a new system. 
Closing unnecessary ports makes your system less susceptible to 
cracking, rootkit infection and/or malware infection.


Am 08.05.20 um 14:33 schrieb Elmar Stellnberger:

  I always use
 > netstat -atupn
That shows all open tcp and udp ports. Invoke this before you start 
Firefox. The list should be empty or only contain sockets on the 
loopback network interface (127.0.0.*, ::1). To disable unnecessary 
network daemons use:

 > systemctl disable avahi-daemon/other-daemon
 > systemctl stop avahi-daemon

   For init opening RPC sockets you may need:
 > systemctl disable rpcbind.socket
 > systemctl stop rpcbind.socket

  You may also uninstall unnecessary software:
 > apt-get remove kdeconnect

View all processes with
 > ps ax
That may also be of help:
 > pstree -p

To identify the executable of a process
 > ls -l /proc/1234/exe

And to identify the package an executable belongs to:
 > dpkg -S /bin/bash

If rkhunter should once not yield the desired results then use 
debcheckroot: https://www.elstel.org/debcheckroot/


Also helpful:
 > systemctl -t service -a

If you have a rootkit that does f.i. infect system libraries like glibc 
you will not see anything in the netstat nor in the ps ax output because 
these utilities can be replaced by utilities that do not return things 
belonging to the rootkit. To be sure that your system is clean you will 
need to use debcheckroot as rkhunter only knows a certain set of well 
known rootkits. However in this case rkhunter may have found something 
though.



Am 08.05.20 um 13:08 schrieb shirish शिरीष:


Anyways, I don't really know much about netstat hence used ss which is
a utility to investigate sockets. Fortunately the version of iproute2
has version 5.6.0-1 which gives the option of doing something like -

# ss -p

Re: rkhunter finds something suspicious

  Take care when you try to analyze the rootkit: You should install new 
into another partition/ boot from live cd first and then look at the 
files without executing them (otherwise your new system may get 
infected). The rootkit may be altered, removed or your activity may be 
monitored and/or inhibited if you try to analyze fromout of an infected 
system.


Am 08.05.20 um 15:48 schrieb Elmar Stellnberger:

Am 07.05.20 um 19:14 schrieb shirish शिरीष:

Dear all,

Today my system was slowing much more than ever. Hence decided to run
rkhunter. It seems to have found some issues, could somebody take a
look and see if these are false positives or what ?


I don't know the hash sums it quotes are current or off-date from the
one debian provides. I did see #651119 but it will be better if
somebody better than me can see if everything is good or off.



   Looks like a kernel rootkit as programs like init, modprobe and 
systemd are reported to be manipulated. That should make sense if 
additional kernel modules and/or daemons are loaded. Since rkhunter 
seems to only report altered files where the locally stored hash has not 
been attacked but not additional files in your system you may 
additionally want to run debcheckroot to find out about such files 
(https://www.elstel.org/debcheckroot/). Anyway, you should reinstall 
your system. You could try to look at the mtime (modification time) of 
the files that are reported to be manipulated and search for other files 
with approximately the same date. Use the find utility to do so:

 > find / -printf "%Y %p # %TY-%Tm-%Td_%TH:%TM %AY-%Am-%Ad %CY-%Cm-%Cd\n"
and:
   There are three timestamps: modification time (m), inode modification 
time (c) - file attributes/creation, and last access time (a). Take care 
of the last access time: even running find on the files may change that 
without using -noatime or sth. the like.

Re: rkhunter finds something suspicious


Am 07.05.20 um 19:14 schrieb shirish शिरीष:

Dear all,

Today my system was slowing much more than ever. Hence decided to run
rkhunter. It seems to have found some issues, could somebody take a
look and see if these are false positives or what ?


I don't know the hash sums it quotes are current or off-date from the
one debian provides. I did see #651119 but it will be better if
somebody better than me can see if everything is good or off.



  Looks like a kernel rootkit as programs like init, modprobe and 
systemd are reported to be manipulated. That should make sense if 
additional kernel modules and/or daemons are loaded. Since rkhunter 
seems to only report altered files where the locally stored hash has not 
been attacked but not additional files in your system you may 
additionally want to run debcheckroot to find out about such files 
(https://www.elstel.org/debcheckroot/). Anyway, you should reinstall 
your system. You could try to look at the mtime (modification time) of 
the files that are reported to be manipulated and search for other files 
with approximately the same date. Use the find utility to do so:

> find / -printf "%Y %p # %TY-%Tm-%Td_%TH:%TM %AY-%Am-%Ad %CY-%Cm-%Cd\n"
and:
  There are three timestamps: modification time (m), inode modification 
time (c) - file attributes/creation, and last access time (a). Take care 
of the last access time: even running find on the files may change that 
without using -noatime or sth. the like.

Re: rkhunter finds something suspicious


 I always use
> netstat -atupn
That shows all open tcp and udp ports. Invoke this before you start 
Firefox. The list should be empty or only contain sockets on the 
loopback network interface (127.0.0.*, ::1). To disable unnecessary 
network daemons use:

> systemctl disable avahi-daemon/other-daemon
> systemctl stop avahi-daemon

  For init opening RPC sockets you may need:
> systemctl disable rpcbind.socket
> systemctl stop rpcbind.socket

 You may also uninstall unnecessary software:
> apt-get remove kdeconnect

View all processes with
> ps ax
That may also be of help:
> pstree -p

To identify the executable of a process
> ls -l /proc/1234/exe

And to identify the package an executable belongs to:
> dpkg -S /bin/bash

If rkhunter should once not yield the desired results then use 
debcheckroot: https://www.elstel.org/debcheckroot/


Also helpful:
> systemctl -t service -a

If you have a rootkit that does f.i. infect system libraries like glibc 
you will not see anything in the netstat nor in the ps ax output because 
these utilities can be replaced by utilities that do not return things 
belonging to the rootkit. To be sure that your system is clean you will 
need to use debcheckroot as rkhunter only knows a certain set of well 
known rootkits. However in this case rkhunter may have found something 
though.



Am 08.05.20 um 13:08 schrieb shirish शिरीष:


Anyways, I don't really know much about netstat hence used ss which is
a utility to investigate sockets. Fortunately the version of iproute2
has version 5.6.0-1 which gives the option of doing something like -

# ss -p

Re: arbitrary code execution on unformatted usb stick

2020-05-02 Thread Elmar Stellnberger

I simply have to give up because I have no clean computer to work on. I 
can now envision better why the BND is said to still use old style 
mechanic typewriters. You can never fully trust electronics, 
namely/especially everything that has a CPU. If you want to communicate 
securely do not use GPG but use a typewriter and snail-mail. I can also 
imagine how I would end up after my studies. I have already received an 
offer to work for the people who have been terrorizing me (but that is 
another tale) ...


Am 02.05.20 um 16:50 schrieb Elmar Stellnberger:

Am 25.04.20 um 15:38 schrieb Elmar Stellnberger:

Dear readers of the debian-security mailing list

   The first time I had lost my new coreboot i7 notebook when I 
plugged a vfat formatted usb stick into the notebook run merely 
offline where I developed the a̅tea. Suddenly low level operating 
system errors appeared and since a power off/power on it refuses to 
boot from any media: internal m2 and usb. The notebook is thus 
unusable. I have sent the computer for repair but I got it back in the 
exactly the same condition. If you like you can read 
https://www.elstel.org/uploads/laptop-note.pdf. It contains an error 
description (I have written it with my typewriter and the company 
scanned the document).
   Consequently I thought that there would be an arbitrary code 
execution bug in the vfat file system. I prepared an USB stick, 
created an msdos partition table with 7 partitions and used tar to 
read and write from the partitions (20-blueusb.rules). However it 
turned out sooner and later that this also caused arbitrary code 
executions. It made my offline Debian installation where I run an 
Apache server to create content for elstel.org several times unusable. 
I simply could not believe it. A program as simple as tar should not 
contain an arbitrary code execution bug! There was no other way the 
system could get in touch with the outside so the usb stick was 
definitely at fault.
   Today I have finally used cat and dd to stitch three text files 
together and read them back from a partition. That way I have avoided 
to use tar. It was on my most secure system which normally does not 
have any contact to other computers at all because the system with the 
Apache server for elstel.org was unsuable for another time. And see 
there I got the exactly same result without tar: After unexplainable 
operating system errors the system does not boot as soon as any SATA 
drive is attached. Flashing the BIOS does not help against this kind 
of error as there is also other firmware. I have seen 3 of my Kingston 
USB readers manipulated to not read a certain sdcard while 3 other 
readers of the same type and same shipping locked in a box did still 
read it (sdcard blue ray image to install a clean Debian10). Obviously 
the firmware of that device was altered. As with the USB card reader a 
computer has many devices each with its own firmware which can be 
altered to damage a computer.
   This time I am at loss. If I can not plug in an USB stick there is 
apparently ¿almost? no safe way to communicate with that computer. 
There needs to be an arbitrary code execution bug hidden in the kernel 
which gets executed as soon as a partition table is read in. As I do 
not have any filesystem on that USB stick and I have automounting 
disabled that should not be due to filesystem probing. As my 
experience with bug reporting at the Firefox browser I am quite sure 
at least some of them are bought by secret services due to their 
unwillingness to fix flagrant bugs. However I would never have 
believed this could be the case with the Linux kernel. A kernel 
developer could perhaps help me if he said what code exactly got 
executed on plugging in an USB stick. Finally I would need to use 
another operating system but I can´t as there is no other distribution 
than Debian which offers a blue ray image for offline installation. 
Downloading singleton files in a batch via tor is conspicuous to 
secret services and thus not viable. They would simply alter the 
download as they have done many times. I wonder how the people at the 
Iranian nuclear progam do their things?


Yours Sincerely,
Elmar Stellnberger



   On from the beginning I had been in doubt about the conclusion of 
what I reported in my last email. Such a bug in the usb mass storage 
driver of the Linux kernel would be extremely hard to hide. From what I 
believe now that supposed bug does not exist. Very likely they have a 
remote control of that offline PC used to maintain elstel.org. They are 
badgering me there too. I already had that with a previous offline 
computer which is of another model/make. I know it for sure with that 
computer since they have hindered me there to program a̅tea. I know it 
from other occasions as well. They knew on my online computer what I was 
doing offline before. Impossible if they have no connection. It is for 
them exactly the way as if that computer were online connected

Re: arbitrary code execution on unformatted usb stick

2020-05-02 Thread Elmar Stellnberger


Am 25.04.20 um 15:38 schrieb Elmar Stellnberger:

Dear readers of the debian-security mailing list

   The first time I had lost my new coreboot i7 notebook when I plugged 
a vfat formatted usb stick into the notebook run merely offline where I 
developed the a̅tea. Suddenly low level operating system errors appeared 
and since a power off/power on it refuses to boot from any media: 
internal m2 and usb. The notebook is thus unusable. I have sent the 
computer for repair but I got it back in the exactly the same condition. 
If you like you can read https://www.elstel.org/uploads/laptop-note.pdf. 
It contains an error description (I have written it with my typewriter 
and the company scanned the document).
   Consequently I thought that there would be an arbitrary code 
execution bug in the vfat file system. I prepared an USB stick, created 
an msdos partition table with 7 partitions and used tar to read and 
write from the partitions (20-blueusb.rules). However it turned out 
sooner and later that this also caused arbitrary code executions. It 
made my offline Debian installation where I run an Apache server to 
create content for elstel.org several times unusable. I simply could not 
believe it. A program as simple as tar should not contain an arbitrary 
code execution bug! There was no other way the system could get in touch 
with the outside so the usb stick was definitely at fault.
   Today I have finally used cat and dd to stitch three text files 
together and read them back from a partition. That way I have avoided to 
use tar. It was on my most secure system which normally does not have 
any contact to other computers at all because the system with the Apache 
server for elstel.org was unsuable for another time. And see there I got 
the exactly same result without tar: After unexplainable operating 
system errors the system does not boot as soon as any SATA drive is 
attached. Flashing the BIOS does not help against this kind of error as 
there is also other firmware. I have seen 3 of my Kingston USB readers 
manipulated to not read a certain sdcard while 3 other readers of the 
same type and same shipping locked in a box did still read it (sdcard 
blue ray image to install a clean Debian10). Obviously the firmware of 
that device was altered. As with the USB card reader a computer has many 
devices each with its own firmware which can be altered to damage a 
computer.
   This time I am at loss. If I can not plug in an USB stick there is 
apparently ¿almost? no safe way to communicate with that computer. There 
needs to be an arbitrary code execution bug hidden in the kernel which 
gets executed as soon as a partition table is read in. As I do not have 
any filesystem on that USB stick and I have automounting disabled that 
should not be due to filesystem probing. As my experience with bug 
reporting at the Firefox browser I am quite sure at least some of them 
are bought by secret services due to their unwillingness to fix flagrant 
bugs. However I would never have believed this could be the case with 
the Linux kernel. A kernel developer could perhaps help me if he said 
what code exactly got executed on plugging in an USB stick. Finally I 
would need to use another operating system but I can´t as there is no 
other distribution than Debian which offers a blue ray image for offline 
installation. Downloading singleton files in a batch via tor is 
conspicuous to secret services and thus not viable. They would simply 
alter the download as they have done many times. I wonder how the people 
at the Iranian nuclear progam do their things?


Yours Sincerely,
Elmar Stellnberger



  On from the beginning I had been in doubt about the conclusion of 
what I reported in my last email. Such a bug in the usb mass storage 
driver of the Linux kernel would be extremely hard to hide. From what I 
believe now that supposed bug does not exist. Very likely they have a 
remote control of that offline PC used to maintain elstel.org. They are 
badgering me there too. I already had that with a previous offline 
computer which is of another model/make. I know it for sure with that 
computer since they have hindered me there to program a̅tea. I know it 
from other occasions as well. They knew on my online computer what I was 
doing offline before. Impossible if they have no connection. It is for 
them exactly the way as if that computer were online connected with a 
LAN cable or Wifi. They can do everything there. There was nothing 
apparently visible on the mainboard but electronic components are small 
and a component could have been replaced. This time it was most likely 
before I have received the mainboard and assembled my computer.
  Consequently as there is no one who would help me and even no one 
whom I can meet in person who would be interested in what I have to tell 
from 2011 I will have to give up my security related engagement. Just 
telling other people about what has happened could help a lot (You

Re: Scripts that run insecurely-downloaded code

2020-05-01 Thread Elmar Stellnberger

https isn´t any more secure than http as long as you do not have a 
verifiably trustworthy server certificate that you can check for. As we 
know the certification authority system is totally broken. It is a bug 
if a build script tries to download something. It must work offline as 
well. I do not see any way than to rewrite these build scripts and pack 
all the necessary sources into the package for compiling it offline.


Am 01.05.20 um 20:54 schrieb Rebecca N. Palmer:
Around 200 packages [0] include upstream scripts that download code via 
(non-secure) http, then run it without an integrity check.


This is obviously a security hole (network MITM => code execution), but 
not necessarily one that is opened by normal use of the package.  (E.g. 
fetch-dependencies-and-build scripts can't download anything on a Debian 
buildd, though it would still make sense to report them to upstream.)


Some instances of this (i.e. where the download origin offers it) are 
trivially improvable by replacing http with https.


How should this be dealt with?
- Mass report?
   - As BTS bugs (i.e. public) or private email?
- (imperfect) Lintian check based on [0]?
- If one is fixed, should it also be fixed in stable?  (Probably depends 
on how likely the script is to be used from the package)


Previous discussions that I can find [1-2] reached no clear conclusion, 
possibly because there were other issues involved (the trustworthiness 
of the downloads' intended origin, and whether downloaders had to be in 
contrib).


[0] codesearch (wget|curl).*http://[^ ]*/[^ 
]*\.(pl|sh|py|gz|xz|bz2|zip)($|[^a-z]) matches 368 packages, but not all 
of them are actual security problems

[1] https://lists.debian.org/debian-security/2012/12/msg00030.html
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=449497

Fwd: Re: AW:webhosting mit DANE

2020-04-25 Thread Elmar Stellnberger

ren einmal an ein paar entsprechende 
Organisationen Blue Ray Images mit nachweisbar gecrackten Systemen 
gesendet, damit das endlich eine unabhängige Stelle bestätigen kann, 
doch Antwort habe ich nie eine bekommen. Ich würde einmal annehmen, daß 
man die letzten Endes zum Schweigen gebracht hat oder warum ist es denen 
nicht einmal eine Antwort wert? Die einzigen die auf meine Nachfrage 
geantwortet haben waren die FSFE, die aber selbst naheliegenderweise im 
Gegensatz zu anderen keine Ressourcen für die Analyse haben (Obwohl ein 
debcheckroot log anschauen auch nicht so viel Arbeit sein kann.).


Schöne Grüße,
Elmar Stellnberger

Re: arbitrary code execution on unformatted usb stick

2020-04-25 Thread Elmar Stellnberger





Am 25.04.20 um 15:38 schrieb Elmar Stellnberger:

Dear readers of the debian-security mailing list

   The first time I had lost my new coreboot i7 notebook when I plugged 
a vfat formatted usb stick into the notebook run merely offline where I 
developed the a̅tea. Suddenly low level operating system errors appeared 
and since a power off/power on it refuses to boot from any media: 
internal m2 and usb. The notebook is thus unusable. I have sent the 
computer for repair but I got it back in the exactly the same condition. 
If you like you can read https://www.elstel.org/uploads/laptop-note.pdf. 
It contains an error description (I have written it with my typewriter 
and the company scanned the document).
   Consequently I thought that there would be an arbitrary code 
execution bug in the vfat file system. I prepared an USB stick, created 
an msdos partition table with 7 partitions and used tar to read and 
write from the partitions (20-blueusb.rules). However it turned out 
sooner and later that this also caused arbitrary code executions. It 
made my offline Debian installation where I run an Apache server to 
create content for elstel.org several times unusable. I simply could not 
believe it. A program as simple as tar should not contain an arbitrary 
code execution bug! There was no other way the system could get in touch 
with the outside so the usb stick was definitely at fault.
   Today I have finally used cat and dd to stitch three text files 
together and read them back from a partition. That way I have avoided to 
use tar. It was on my most secure system which normally does not have 
any contact to other computers at all because the system with the Apache 
server for elstel.org was unsuable for another time. And see there I got 
the exactly same result without tar: After unexplainable operating 
system errors the system does not boot as soon as any SATA drive is 
attached. Flashing the BIOS does not help against this kind of error as 
there is also other firmware. I have seen 3 of my Kingston USB readers 
manipulated to not read a certain sdcard while 3 other readers of the 
same type and same shipping locked in a box did still read it (sdcard 
blue ray image to install a clean Debian10). Obviously the firmware of 
that device was altered. As with the USB card reader a computer has many 
devices each with its own firmware which can be altered to damage a 
computer.
   This time I am at loss. If I can not plug in an USB stick there is 
apparently ¿almost? no safe way to communicate with that computer. There 
needs to be an arbitrary code execution bug hidden in the kernel which 
gets executed as soon as a partition table is read in. As I do not have 


I do  not believe the problem is about the msdos partition table as this 
one is even more simple than invoking tar. But there could (and finally 
needs) to be hidden something in the usb mass storage driver?!



any filesystem on that USB stick and I have automounting disabled that 
should not be due to filesystem probing. As my experience with bug 
reporting at the Firefox browser I am quite sure at least some of them 
are bought by secret services due to their unwillingness to fix flagrant 
bugs. However I would never have believed this could be the case with 
the Linux kernel. A kernel developer could perhaps help me if he said 
what code exactly got executed on plugging in an USB stick. Finally I 
would need to use another operating system but I can´t as there is no 
other distribution than Debian which offers a blue ray image for offline 
installation. Downloading singleton files in a batch via tor is 
conspicuous to secret services and thus not viable. They would simply 
alter the download as they have done many times. I wonder how the people 
at the Iranian nuclear progam do their things?


Yours Sincerely,
Elmar Stellnberger

arbitrary code execution on unformatted usb stick

2020-04-25 Thread Elmar Stellnberger


Dear readers of the debian-security mailing list

  The first time I had lost my new coreboot i7 notebook when I plugged 
a vfat formatted usb stick into the notebook run merely offline where I 
developed the a̅tea. Suddenly low level operating system errors appeared 
and since a power off/power on it refuses to boot from any media: 
internal m2 and usb. The notebook is thus unusable. I have sent the 
computer for repair but I got it back in the exactly the same condition. 
If you like you can read https://www.elstel.org/uploads/laptop-note.pdf. 
It contains an error description (I have written it with my typewriter 
and the company scanned the document).
  Consequently I thought that there would be an arbitrary code 
execution bug in the vfat file system. I prepared an USB stick, created 
an msdos partition table with 7 partitions and used tar to read and 
write from the partitions (20-blueusb.rules). However it turned out 
sooner and later that this also caused arbitrary code executions. It 
made my offline Debian installation where I run an Apache server to 
create content for elstel.org several times unusable. I simply could not 
believe it. A program as simple as tar should not contain an arbitrary 
code execution bug! There was no other way the system could get in touch 
with the outside so the usb stick was definitely at fault.
  Today I have finally used cat and dd to stitch three text files 
together and read them back from a partition. That way I have avoided to 
use tar. It was on my most secure system which normally does not have 
any contact to other computers at all because the system with the Apache 
server for elstel.org was unsuable for another time. And see there I got 
the exactly same result without tar: After unexplainable operating 
system errors the system does not boot as soon as any SATA drive is 
attached. Flashing the BIOS does not help against this kind of error as 
there is also other firmware. I have seen 3 of my Kingston USB readers 
manipulated to not read a certain sdcard while 3 other readers of the 
same type and same shipping locked in a box did still read it (sdcard 
blue ray image to install a clean Debian10). Obviously the firmware of 
that device was altered. As with the USB card reader a computer has many 
devices each with its own firmware which can be altered to damage a 
computer.
  This time I am at loss. If I can not plug in an USB stick there is 
apparently ¿almost? no safe way to communicate with that computer. There 
needs to be an arbitrary code execution bug hidden in the kernel which 
gets executed as soon as a partition table is read in. As I do not have 
any filesystem on that USB stick and I have automounting disabled that 
should not be due to filesystem probing. As my experience with bug 
reporting at the Firefox browser I am quite sure at least some of them 
are bought by secret services due to their unwillingness to fix flagrant 
bugs. However I would never have believed this could be the case with 
the Linux kernel. A kernel developer could perhaps help me if he said 
what code exactly got executed on plugging in an USB stick. Finally I 
would need to use another operating system but I can´t as there is no 
other distribution than Debian which offers a blue ray image for offline 
installation. Downloading singleton files in a batch via tor is 
conspicuous to secret services and thus not viable. They would simply 
alter the download as they have done many times. I wonder how the people 
at the Iranian nuclear progam do their things?


Yours Sincerely,
Elmar Stellnberger
# man 7 udev
# cat /sys/bus/usb/devices/2-1/serial
# cat /sys/bus/usb/devices/2-1/product -> USB Mass Storage Device
#SUBSYSTEM=="usb", ATTRS{serial}=="0002C7", MODE="0660", GROUP="100"
SUBSYSTEM=="block", ATTRS{serial}=="0002C7", ENV{PARTN}!="1", 
SYMLINK+="blueusb%n", MODE="0666"

Re: debcheckroot v2.0 released

2020-04-07 Thread Elmar Stellnberger


Am 04.04.20 um 09:47 schrieb Elmar Stellnberger:

Am 02.04.20 um 16:49 schrieb Elmar Stellnberger:

Am 02.04.20 um 01:57 schrieb Paul Wise:

On Wed, Apr 1, 2020 at 6:01 PM vi...@vheuser.com wrote:


Did the discussion of continuing support for DANE end??


In case I mislead anyone, a clarification:

Debian itself isn't going to actively work on removing support for
DANE from anything nor removing our DANE/DNSSEC records.

Support for DANE is never going to happen for the web (given the
opinions of the major browser makers) and it could disappear in other
upstream projects as the popularity of DoH/DoT and other things in the
DNS space eclipse DANE/DNSSEC. Should that happen to the software
Debian uses for DNS/DANE, we may be forced to drop our DANE/DNSSEC
records.



What software is currently used for DNSSEC/DANE by Debian?
What do you mean by DoH/DoT?



Dear Paul,

   Can you answer us that question: What software does Debian use that 
supports DANE? I do not know of any except dig and drill.


Yours,
Elmar Stellnberger


ping

Re: debcheckroot v2.0 released

2020-04-04 Thread Elmar Stellnberger


Am 02.04.20 um 16:49 schrieb Elmar Stellnberger:

Am 02.04.20 um 01:57 schrieb Paul Wise:

On Wed, Apr 1, 2020 at 6:01 PM vi...@vheuser.com wrote:


Did the discussion of continuing support for DANE end??


In case I mislead anyone, a clarification:

Debian itself isn't going to actively work on removing support for
DANE from anything nor removing our DANE/DNSSEC records.

Support for DANE is never going to happen for the web (given the
opinions of the major browser makers) and it could disappear in other
upstream projects as the popularity of DoH/DoT and other things in the
DNS space eclipse DANE/DNSSEC. Should that happen to the software
Debian uses for DNS/DANE, we may be forced to drop our DANE/DNSSEC
records.



What software is currently used for DNSSEC/DANE by Debian?
What do you mean by DoH/DoT?



Dear Paul,

  Can you answer us that question: What software does Debian use that 
supports DANE? I do not know of any except dig and drill.


Yours,
Elmar Stellnberger

Re: debcheckroot v2.0 released

2020-04-04 Thread Elmar Stellnberger





Am 04.04.20 um 00:46 schrieb Lee:

On 4/3/20, Elmar Stellnberger  wrote:

Encryption can be a source of arbitrary code execution exploits if not
implemented properly. Encrypting DNS would have other application
purposes and makes sense as long as you use a proxy. If you connect
directly hiding the domain name is ineffective because someone who spys
at the connection also knows the IPs you connect to and via SNI the
cleartext of the domain you surf at.


Yes, but "trusting the answer" and "keeping my communications private"
are not quite the same thing.  If we're talking about "trusting the
answer" I'll take DoT or running my own dnssec enabled resolver.  When
I'm more concerned about "keeping my communications private" I'll take
TOR & accept the trade-off of slower speed.



  I think we have to separate two issues here: authenticity asserting 
that the answer is correct and confidentiality asserting that no one 
else knows about a message. Signing asserts authenticity while 
encryption can guarantee confidentiality. With GnuPG encrypted messages 
are also signed by default so that both features are provided. That does 
not tell however that both issues are clearly separated. Encryption by 
itself does not contribute anything to the authenticity of a reply, i.e. 
you do not know from whom it came. With signing the correctness of an 
answer can be asserted but the answer itself can be read in cleartext by 
everyone unless it is additionally encrypted.

Re: debcheckroot v2.0 released

2020-04-03 Thread Elmar Stellnberger

   There are a few reasons why I believe that DANE / TLSA DNS RR answers 
are quite trustworthy:


* DNS responses are much faster than establishing a TCP connection 
(1.5RTT), usually only about 40ms also because DNS servers tend to be 
near the user if not provided by the ISP while the server you wanna 
contact is usually in another country or another federal state. As we 
know from the Snowden Revelations spoofing connections only works if the 
spoofed response is faster than the original response. My idea about it 
is that the NSA and related intelligence simply do not have an 
infrastructure to spoof DNS responses.


* There is a public/private key signing infrastructure for DANE as well 
but I consider that more secure than a gpg private key used on a system 
with emailing or web browsing. I believe it is much more hard to get 
into a server than is to get into a client.


   Finally DANE has been invented for the reason to restore trust in the 
internet - as it was there initially when there was no operation Quantum 
insert or similar operations. I´d believe the DANE system has been 
designed secure as to serve its purpose. Finally my own practical 
experience with DANE is very positive. It appeared to be the only way to 
prevent site spoofing:

https://lists.debian.org/debian-security/2020/01/threads.html
https://lists.debian.org/debian-security/2020/02/threads.html
https://lists.debian.org/debian-security/2020/03/threads.html

   The reason why browser developers have not adopted DANE yet is that 
they side with intelligence (secret services) as the following bug 
report shows me:

https://bugzilla.mozilla.org/show_bug.cgi?id=1606802

   I had also linked this report in my previous discussion at 
debian-security.




  Finally I have forgotten about the most important reason why DANE is 
much more secure than other methods:


* There is a regular, secure and automatic key rotation for DANE. With 
GnuPG keys can be happily stolen as they remain valid for a year or more 
and as there is no secure way to redistribute a new key.


  Concerning DoH/DoT I would rather believe these technologies to be 
detrimental as encryption adds an additional error prone overhead but 
does not contribute anything to the authenticity of the reply. 
Encryption can be a source of arbitrary code execution exploits if not 
implemented properly. Encrypting DNS would have other application 
purposes and makes sense as long as you use a proxy. If you connect 
directly hiding the domain name is ineffective because someone who spys 
at the connection also knows the IPs you connect to and via SNI the 
cleartext of the domain you surf at.

Re: debcheckroot v2.0 released

2020-04-03 Thread Elmar Stellnberger





Am 02.04.20 um 16:55 schrieb Elmar Stellnberger:

Am 02.04.20 um 11:15 schrieb Lewis Yarema:

But we have the atea tool now. Haven't we? You can use it to download
via DNSSEC/DANE. And I believe Elmar is going to continue support for
it. Debian itself can always support DANE as long as there are working
DNSSEC impementations. Just provide a TLSA record. And I would believe
that to be valuable since the problem about DNSSEC/DANE support is a
bit like the hen and egg problem.



   Yes, sure, I am going to support a̅tea in the future. Support of 
security related programs and especially of a̅tea have absolute priority 
for me. I do what I can. The program appears so important to me because 
according to my knowledge there is no other program you can use for 
download with user supplied security certificate. wget and curl do all 
require you to trust a possibly untrustworthy CA. Besides this you can 
use DANE without direct support by any program. I have described who to 
do that by use of dig or drill at https://www.elstel.org/DANE/.




  If there is someone else who has never heard about a̅tea:
https://www.elstel.org/atea/

You may have missed my previous messages from debian-security:
https://lists.debian.org/debian-security/2020/03/threads.html
https://lists.debian.org/debian-security/2020/01/threads.html

  Vince asked me because he did not get these messages to read though 
he was subscribed.


  I also can´t explain why Patrick Schleizer did no more respond me 
though I have finally posted the message for him to this list.

https://lists.debian.org/debian-security/2020/03/msg00017.html

  He is also subscribed and would need to have seen my posting. As it 
seems some people here don´t get my messages.

Re: debcheckroot v2.0 released

2020-04-02 Thread Elmar Stellnberger


Am 02.04.20 um 20:50 schrieb Lee:

On 4/1/20, Paul Wise  wrote:

On Wed, Apr 1, 2020 at 6:01 PM vince@ wrote:


Did the discussion of continuing support for DANE end??


In case I mislead anyone, a clarification:

Debian itself isn't going to actively work on removing support for
DANE from anything nor removing our DANE/DNSSEC records.

Support for DANE is never going to happen for the web (given the
opinions of the major browser makers)


Can you share a reference for that?

I can see browsers not trusting the client DNS since they can't tell
if the client resolver is using DNSSEC or not  (ie. they can't tell if
the DANE answer is valid).  But now that DOH is supported it seems
like browsers could trust DOH servers that [promise to] do DNSSEC, so
now they could trust DANE?

eg - the firefox DOH server seems to have DNSSEC enabled:

$ curl -H 'accept: application/dns-json' \
 
'https://mozilla.cloudflare-dns.com/dns-query?name=servfail.sidnlabs.nl=a'
{"Status": 2,"TC": false,"RD": true, "RA": true, "AD": false,"CD":
false,"Question":[{"name": "servfail.sidnlabs.nl.", "type":
1}],"Comment": "DNSSEC validation failure. Please check
http://dnsviz.net/d/servfail.sidnlabs.nl/dnssec/"}

so maybe the tlsa answer can be trusted?

$ curl -H 'accept: application/dns-json' \
   
'https://mozilla.cloudflare-dns.com/dns-query?name=_443._tcp.debian.org=tlsa'
{"Status": 0,"TC": false,"RD": true, "RA": true, "AD": true,"CD":
false,"Question":[{"name": "_443._tcp.debian.org.", "type":
52}],"Answer":[{"name": "_443._tcp.debian.org.", "type": 52, "TTL":
600, "data": "3 1 1
5F33491E2B2D267F7BFF096AD0DCB4AE5A22C0BE19DB0AB6728BED942F0719FC"}]}

Thanks,
Lee

  There are a few reasons why I believe that DANE / TLSA DNS RR answers 
are quite trustworthy:


* DNS responses are much faster than establishing a TCP connection 
(1.5RTT), usually only about 40ms also because DNS servers tend to be 
near the user if not provided by the ISP while the server you wanna 
contact is usually in another country or another federal state. As we 
know from the Snowden Revelations spoofing connections only works if the 
spoofed response is faster than the original response. My idea about it 
is that the NSA and related intelligence simply do not have an 
infrastructure to spoof DNS responses.


* There is a public/private key signing infrastructure for DANE as well 
but I consider that more secure than a gpg private key used on a system 
with emailing or web browsing. I believe it is much more hard to get 
into a server than is to get into a client.


  Finally DANE has been invented for the reason to restore trust in the 
internet - as it was there initially when there was no operation Quantum 
insert or similar operations. I´d believe the DANE system has been 
designed secure as to serve its purpose. Finally my own practical 
experience with DANE is very positive. It appeared to be the only way to 
prevent site spoofing:

https://lists.debian.org/debian-security/2020/01/threads.html
https://lists.debian.org/debian-security/2020/02/threads.html
https://lists.debian.org/debian-security/2020/03/threads.html

  The reason why browser developers have not adopted DANE yet is that 
they side with intelligence (secret services) as the following bug 
report shows me:

https://bugzilla.mozilla.org/show_bug.cgi?id=1606802

  I had also linked this report in my previous discussion at 
debian-security.

Re: debcheckroot v2.0 released

2020-04-02 Thread Elmar Stellnberger


Am 02.04.20 um 11:15 schrieb Lewis Yarema:

But we have the atea tool now. Haven't we? You can use it to download
via DNSSEC/DANE. And I believe Elmar is going to continue support for
it. Debian itself can always support DANE as long as there are working
DNSSEC impementations. Just provide a TLSA record. And I would believe
that to be valuable since the problem about DNSSEC/DANE support is a
bit like the hen and egg problem.



  Yes, sure, I am going to support a̅tea in the future. Support of 
security related programs and especially of a̅tea have absolute priority 
for me. I do what I can. The program appears so important to me because 
according to my knowledge there is no other program you can use for 
download with user supplied security certificate. wget and curl do all 
require you to trust a possibly untrustworthy CA. Besides this you can 
use DANE without direct support by any program. I have described who to 
do that by use of dig or drill at https://www.elstel.org/DANE/.

Re: debcheckroot v2.0 released

2020-04-02 Thread Elmar Stellnberger


Am 02.04.20 um 01:57 schrieb Paul Wise:

On Wed, Apr 1, 2020 at 6:01 PM vi...@vheuser.com wrote:


Did the discussion of continuing support for DANE end??


In case I mislead anyone, a clarification:

Debian itself isn't going to actively work on removing support for
DANE from anything nor removing our DANE/DNSSEC records.

Support for DANE is never going to happen for the web (given the
opinions of the major browser makers) and it could disappear in other
upstream projects as the popularity of DoH/DoT and other things in the
DNS space eclipse DANE/DNSSEC. Should that happen to the software
Debian uses for DNS/DANE, we may be forced to drop our DANE/DNSSEC
records.



What software is currently used for DNSSEC/DANE by Debian?
What do you mean by DoH/DoT?

Re: debcheckroot v2.0 released

2020-03-26 Thread Elmar Stellnberger


Am 26.03.20 um 03:50 schrieb Paul Wise:

On Wed, 2020-03-25 at 11:27 +0100, Elmar Stellnberger wrote:


OpenPGP is no solution to the issue.
DANE is not gonna disappear.


I guess we will have to agree to disagree, end of thread for me.



  I am far from not having to say more about it. Most people who 
provide signatures store their private key on a machine also used for 
web browsing. I know this also applies to Debian because keeping the key 
secure or at best offline would require some considerable provisions and 
AFAIK none of you have implemented a separation of concerns i.e. one 
computer for browsing and another one for secure ssh connections.
  That would be required though to keep the secret key safe. We have an 
arbitrary code execution bug in browsers every few month and that does 
not count all the zero day exploits at all. Sites in the www are 
commonly spoofed by secret services. Even the Snowden revelations do 
tell (operation Quantum insert). That way the secret key is guaranteed 
to be compromised a few milliseconds after its creation. The NSA also 
has its own key stealing programme. I wanna tell you that you are better 
off checking the SHA512SUM. That one, as soon as you have retrieved a 
genuine one, can no more be spoofed.
  Besides this it is a common attack vector to infect computers via 
online updates. Once more they need to know the secret key in order to 
do so!

Re: debcheckroot v2.0 released

2020-03-25 Thread Elmar Stellnberger


Am 25.03.20 um 02:50 schrieb Paul Wise:

On Tue, 2020-03-24 at 15:48 +0100, Elmar Stellnberger wrote:


I hope this is gonna happen anytime soon. DANE and thus a valid TLSA
record is of very high value and importance for getting a genuine
download of Debian. As I have mentioned before downloads via Tor can be
spoofed like my last Debian Live 10 download which turned out to be
infected by debchecheckrooting against the Debian 10 DL-BD.


TBH, very few people care about DNSSEC and vastly fewer than that care
about DANE so I expect at some point support for both will disappear
from both the DNS root servers and all DNS software.

You shouldn't be relying on DNSSEC/DANE/TLS to verify Debian image
downloads anyway, since they have OpenPGP signatures:

https://www.debian.org/CD/faq/#verify
https://www.debian.org/CD/verify



  OpenPGP is no solution to the issue. You need to download the public 
key and this is usually done over insecure https without DANE. 
Furthermore it is a vibrant issue that the private key can be stolen 
even if it is stored offline. How does Debian guard its private key? Is 
the key used to sign Debian CD images put offline? What security 
measures do apply?
  DANE is not gonna disappear. There is no DANE support for the www yet 
but mail servers do increasingly use DANE. Many public hosters support 
DNSSEC these days and adding a TLSA record is usually little work if you 
are in the possession of the server infrastructure. Third, as we have a 
tool to download over DANE/https now (a̅tea) I would suggest that we 
should make use of it. According to my experience use of DANE is the 
only way around this security nightmare. It has proven to hold strong 
and secure in practice. DANE per se will never disappear as it is the 
decision of the server maintainers whether to provide a TLSA record or 
not. DNSSEC per se is used more than DANE.

Re: debcheckroot v2.0 released

2020-03-24 Thread Elmar Stellnberger


Am 24.03.20 um 11:18 schrieb Paul Wise:

On Tue, Mar 24, 2020 at 3:33 AM Paul Wise wrote:


I've forwarded this to the Debian sysadmins IRC channel. I think it is
related to the fact that the cdimage.d.o server is not managed by the
Debian sysadmins, so the UMU ACC admins probably used Lets Encrypt to
get certs, and then of course the TLSA records got outdated after the
renewal. For other debian.org domains that are not managed by the
Debian sysadmins, we centrally create the certs and propagate them to
external services (like the CDNs for deb.d.o). The cdimage.d.o server
isn't a CDN and probably doesn't have cert APIs but we can probably
use the same approach to fix this.


The result was that the mismatch was caused by a bug in the Debian
sysadmin puppet. The fix was to remove the TLSA records for this
domain due to the aforementioned management disconnect. If the cert
management for cdimage.d.o changes to the deb.d.o setup then the TLSA
records will return and be correct.



  I hope this is gonna happen anytime soon. DANE and thus a valid TLSA 
record is of very high value and importance for getting a genuine 
download of Debian. As I have mentioned before downloads via Tor can be 
spoofed like my last Debian Live 10 download which turned out to be 
infected by debchecheckrooting against the Debian 10 DL-BD.

Re: debcheckroot v2.0 released

2020-03-23 Thread Elmar Stellnberger

I have just released a̅tea v0.6: https://www.elstel.org/atea/ . It now
implements SNI (Server Name Indication) and can thus also be
successfully used to download files like my public gpg key from elstel.org.

atea tii-cert -rv https://cdimage.debian.org
TLSA record (first three bytes are for TLSA-mode):
03:01:01:0c:8e:2d:2b:49:50:6b:cc:77:f7:70:5d:ee:69:fe:a2:30:93:55:5e:88:a2:68:4c:79:8b:8c:e1:84:2b:32:6f
hash of the server certificate:
7d:86:1f:c8:c6:d0:54:ec:74:81:3e:c4:0d:7e:14:45:50:1f:0d:0a:50:11:f1:44:bf:85:cc:6e:2f:8f:cd:ee
certificate signature in TLSA record did not match
(https://cdimage.debian.org)

server cert written to 'cdimage.debian.org-rogue.pem'.

The only site which is still making problems is cdimage.debian.org.
Could any good Christ from the Debian community have a look at this
issue. The server maintainers would need to complain about the rogue cert!

Am 04.03.20 um 20:57 schrieb Elmar Stellnberger:
If anyone wants to play with atea use it under GPLv3. I forgot to add
the license header in the file but this email should entitle you to use
the program under GPLv3.

Elmar

Am 04.03.20 um 20:51 schrieb Elmar Stellnberger:
Hint: You can use -v to get a more verbose output if atea fails which
includes the sha256 hash of the certificate (-vv would also be
possible). From version 0.5 on atea should also do it without the
--sys-keyfile option. For me atea succeeds with domains like
mail.dotplex.com, secure.dotplex.de or web4.dotplex.com. Pages like
ssl-tools.net do already cause problems and my own domain
www.elstel.org could sometimes be reached em ordem and sometimes not
(see the two certificates in the https://www.elstel.org/DANE/ tar file
which have the same start and ending date, one of them is a rogue
certificate). The only domain where I have never succeeded is
cdimage.debian.org. Is it permanently spoofed or did the Debian
maintainers just enter a wrong hash in the TLSA record?

Am 04.03.20 um 20:41 schrieb Elmar Stellnberger:
It would be a question if anyone has tried to download a SHA512SUMS
file from cdimage.debian.org with atea? As it turned out downloading
this file with tails/tor is NOT sufficient. I have verified a Debian
Live 10.1.0 DVD image against the Debian 10.1.0 Install BD-DL I have.
Debcheckroot reported several infected packages like mkinitramfs,
ispell and several pam-modules though mounting the squashfs may
already have triggered some malware.

Yours Sincerely
Elmar Stellnberger

Am 04.03.20 um 20:04 schrieb Elmar Stellnberger:

Hi folks

You can now download the indicated program at
https://www.elstel.org/atea/ and read some documentation at
https://www.elstel.org/DANE/.

Kind Regards,
Elmar

Am 17.01.20 um 16:52 schrieb Elmar Stellnberger:

Hi Cindy Sue! Hi folks!

I must confess there is little you can do about missing emails
with debcheckroot. You can spot rootkits with hindsight but
intelligence can also break in and go without leaving any trace.
What would to my mind be necessary for a more secure email
communication is a better penetration of DANE. Many CAs are known
to issue rogue certificates to secret services so the public key is
the only thing that may be trustworthy of a certificate. If that
public key is signed and bound to a domain with DNSSEC (this is
then called DANE) it shall be safe. I would guess that email
dispatching was If safe if encrypted and saved by DANE all the way
to its target. F.i. it seems likely that intelligence just tries to
halt email delivery if some suspicious email is in the queue until
they have assessed what they wanna do about it. And it is
questionable how those emails which seem to be sent successfully
but which do not reach their target get lost.

Something I as an end user can do about the emailing problem is
to write and send my emails on a secure machine. If I am using
webmail or an emailing program this requires to preconfigure
certificates known to be safe and to only allow these. All CAs need
to be disabled since the average user will never know which CAs
issue rogue certificates. According to my knowledge any simple web
page invocation immediately results in a cracked system if it is
using a spoofed certificate which can not be excluded for any
simple web search. Luckily my hoster provides DANE for the machines
used for email delivery, webmailing and my website configuration
panel. And I am still using a Debian 8 read only stick to boot such
a secure system.

Why the hell Debian 8? Isn`t that insecure? I believe it isn`t
as long as I only visit these two web pages of my hoster.
Unfortunately newer versions of Firefox have a special
implementation for so called HSTS (http strict transport security)
certificates. You can not add a security exception for such a
certificate but you need to configure all dependent certification
authorities for such a certificate. However with the first CA you
acknowledge you compromise your system`s

Re: debcheckroot v2.0 released

2020-03-21 Thread Elmar Stellnberger


https://www.elstel.org/Teorema.html.en
Teorema - a modern portuguese short story, freshly translated into 
English and German

:: Debianopolis - o povo cristão

Am 04.03.20 um 20:41 schrieb Elmar Stellnberger:
It would be a question if anyone has tried to download a SHA512SUMS file 
from cdimage.debian.org with atea? As it turned out downloading this 
file with tails/tor is NOT sufficient. I have verified a Debian Live 
10.1.0 DVD image against the Debian 10.1.0 Install BD-DL I have. 
Debcheckroot reported several infected packages like mkinitramfs, ispell 
and several pam-modules though mounting the squashfs may already have 
triggered some malware.


Yours Sincerely
Elmar Stellnberger



Am 04.03.20 um 20:04 schrieb Elmar Stellnberger:

Hi folks

   You can now download the indicated program at 
https://www.elstel.org/atea/ and read some documentation at 
https://www.elstel.org/DANE/.


Kind Regards,
Elmar

Re: debcheckroot v2.0 released

If anyone wants to play with atea use it under GPLv3. I forgot to add 
the license header in the file but this email should entitle you to use 
the program under GPLv3.


Elmar

Am 04.03.20 um 20:51 schrieb Elmar Stellnberger:
Hint: You can use -v to get a more verbose output if atea fails which 
includes the sha256 hash of the certificate (-vv would also be 
possible). From version 0.5 on atea should also do it without the 
--sys-keyfile option. For me atea succeeds with domains like 
mail.dotplex.com, secure.dotplex.de or web4.dotplex.com. Pages like 
ssl-tools.net do already cause problems and my own domain www.elstel.org 
could sometimes be reached em ordem and sometimes not (see the two 
certificates in the https://www.elstel.org/DANE/ tar file which have the 
same start and ending date, one of them is a rogue certificate). The 
only domain where I have never succeeded is cdimage.debian.org. Is it 
permanently spoofed or did the Debian maintainers just enter a wrong 
hash in the TLSA record?


Am 04.03.20 um 20:41 schrieb Elmar Stellnberger:
It would be a question if anyone has tried to download a SHA512SUMS 
file from cdimage.debian.org with atea? As it turned out downloading 
this file with tails/tor is NOT sufficient. I have verified a Debian 
Live 10.1.0 DVD image against the Debian 10.1.0 Install BD-DL I have. 
Debcheckroot reported several infected packages like mkinitramfs, 
ispell and several pam-modules though mounting the squashfs may 
already have triggered some malware.


Yours Sincerely
Elmar Stellnberger



Am 04.03.20 um 20:04 schrieb Elmar Stellnberger:

Hi folks

   You can now download the indicated program at 
https://www.elstel.org/atea/ and read some documentation at 
https://www.elstel.org/DANE/.


Kind Regards,
Elmar

Am 17.01.20 um 16:52 schrieb Elmar Stellnberger:

Hi Cindy Sue! Hi folks!

   I must confess there is little you can do about missing emails 
with debcheckroot. You can spot rootkits with hindsight but 
intelligence can also break in and go without leaving any trace. 
What would to my mind be necessary for a more secure email 
communication is a better penetration of DANE. Many CAs are known to 
issue rogue certificates to secret services so the public key is the 
only thing that may be trustworthy of a certificate. If that public 
key is signed and bound to a domain with DNSSEC (this is then called 
DANE) it shall be safe. I would guess that email dispatching was If 
safe if encrypted and saved by DANE all the way to its target. F.i. 
it seems likely that intelligence just tries to halt email delivery 
if some suspicious email is in the queue until they have assessed 
what they wanna do about it. And it is questionable how those emails 
which seem to be sent successfully but which do not reach their 
target get lost.


    Something I as an end user can do about the emailing problem is 
to write and send my emails on a secure machine. If I am using 
webmail or an emailing program this requires to preconfigure 
certificates known to be safe and to only allow these. All CAs need 
to be disabled since the average user will never know which CAs 
issue rogue certificates. According to my knowledge any simple web 
page invocation immediately results in a cracked system if it is 
using a spoofed certificate which can not be excluded for any simple 
web search. Luckily my hoster provides DANE for the machines used 
for email delivery, webmailing and my website configuration panel. 
And I am still using a Debian 8 read only stick to boot such a 
secure system.


    Why the hell Debian 8? Isn`t that insecure? I believe it isn`t 
as long as I only visit these two web pages of my hoster. 
Unfortunately newer versions of Firefox have a special 
implementation for so called HSTS (http strict transport security) 
certificates. You can not add a security exception for such a 
certificate but you need to configure all dependent certification 
authorities for such a certificate. However with the first CA you 
acknowledge you compromise your system`s security. Older versions of 
Firefox did not have this bug: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1606802


   I am currently looking forward to test which versions of Debian 9 
would work. Firefox from Debian 10 does no more work. If you have 
good luck your webmailing server supports DANE but does not use 
HSTS. Then you can use a current Debian. With Debian 8 you simply 
need to delete libnssckbi.so from libnss3 to disable all default 
CAs. You can not delete them by hand. If you do you need to mark 
every singleton CA but that does not prevent all deleted CAs to 
reappear a second after you have deleted them. That is why you 
needed to delete the .so. With newer versions of Firefox deleting 
libnssckbi.so does not stay without side effects: You can then not 
acknowledge security exceptions by hand any more. I have written a 
script to do that automatically though and I am likely to publish it 
at https://www.elstel.org

Re: debcheckroot v2.0 released

Hint: You can use -v to get a more verbose output if atea fails which 
includes the sha256 hash of the certificate (-vv would also be 
possible). From version 0.5 on atea should also do it without the 
--sys-keyfile option. For me atea succeeds with domains like 
mail.dotplex.com, secure.dotplex.de or web4.dotplex.com. Pages like 
ssl-tools.net do already cause problems and my own domain www.elstel.org 
could sometimes be reached em ordem and sometimes not (see the two 
certificates in the https://www.elstel.org/DANE/ tar file which have the 
same start and ending date, one of them is a rogue certificate). The 
only domain where I have never succeeded is cdimage.debian.org. Is it 
permanently spoofed or did the Debian maintainers just enter a wrong 
hash in the TLSA record?


Am 04.03.20 um 20:41 schrieb Elmar Stellnberger:
It would be a question if anyone has tried to download a SHA512SUMS file 
from cdimage.debian.org with atea? As it turned out downloading this 
file with tails/tor is NOT sufficient. I have verified a Debian Live 
10.1.0 DVD image against the Debian 10.1.0 Install BD-DL I have. 
Debcheckroot reported several infected packages like mkinitramfs, ispell 
and several pam-modules though mounting the squashfs may already have 
triggered some malware.


Yours Sincerely
Elmar Stellnberger



Am 04.03.20 um 20:04 schrieb Elmar Stellnberger:

Hi folks

   You can now download the indicated program at 
https://www.elstel.org/atea/ and read some documentation at 
https://www.elstel.org/DANE/.


Kind Regards,
Elmar

Am 17.01.20 um 16:52 schrieb Elmar Stellnberger:

Hi Cindy Sue! Hi folks!

   I must confess there is little you can do about missing emails 
with debcheckroot. You can spot rootkits with hindsight but 
intelligence can also break in and go without leaving any trace. What 
would to my mind be necessary for a more secure email communication 
is a better penetration of DANE. Many CAs are known to issue rogue 
certificates to secret services so the public key is the only thing 
that may be trustworthy of a certificate. If that public key is 
signed and bound to a domain with DNSSEC (this is then called DANE) 
it shall be safe. I would guess that email dispatching was safe if 
encrypted and saved by DANE all the way to its target. F.i. it seems 
likely that intelligence just tries to halt email delivery if some 
suspicious email is in the queue until they have assessed what they 
wanna do about it. And it is questionable how those emails which seem 
to be sent successfully but which do not reach their target get lost.


    Something I as an end user can do about the emailing problem is 
to write and send my emails on a secure machine. If I am using 
webmail or an emailing program this requires to preconfigure 
certificates known to be safe and to only allow these. All CAs need 
to be disabled since the average user will never know which CAs issue 
rogue certificates. According to my knowledge any simple web page 
invocation immediately results in a cracked system if it is using a 
spoofed certificate which can not be excluded for any simple web 
search. Luckily my hoster provides DANE for the machines used for 
email delivery, webmailing and my website configuration panel. And I 
am still using a Debian 8 read only stick to boot such a secure system.


    Why the hell Debian 8? Isn`t that insecure? I believe it isn`t as 
long as I only visit these two web pages of my hoster. Unfortunately 
newer versions of Firefox have a special implementation for so called 
HSTS (http strict transport security) certificates. You can not add a 
security exception for such a certificate but you need to configure 
all dependent certification authorities for such a certificate. 
However with the first CA you acknowledge you compromise your 
system`s security. Older versions of Firefox did not have this bug: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1606802


   I am currently looking forward to test which versions of Debian 9 
would work. Firefox from Debian 10 does no more work. If you have 
good luck your webmailing server supports DANE but does not use HSTS. 
Then you can use a current Debian. With Debian 8 you simply need to 
delete libnssckbi.so from libnss3 to disable all default CAs. You can 
not delete them by hand. If you do you need to mark every singleton 
CA but that does not prevent all deleted CAs to reappear a second 
after you have deleted them. That is why you needed to delete the 
.so. With newer versions of Firefox deleting libnssckbi.so does not 
stay without side effects: You can then not acknowledge security 
exceptions by hand any more. I have written a script to do that 
automatically though and I am likely to publish it at 
https://www.elstel.org/DANE/ in the future if sufficient interest is 
given in the issue. Once I know the last good Firefox version I could 
also approach to resolve the bug from above for newer Firefox 
versions. Unfortunately Dana Keeler has given this bug

Re: debcheckroot v2.0 released

It would be a question if anyone has tried to download a SHA512SUMS file 
from cdimage.debian.org with atea? As it turned out downloading this 
file with tails/tor is NOT sufficient. I have verified a Debian Live 
10.1.0 DVD image against the Debian 10.1.0 Install BD-DL I have. 
Debcheckroot reported several infected packages like mkinitramfs, ispell 
and several pam-modules though mounting the squashfs may already have 
triggered some malware.


Yours Sincerely
Elmar Stellnberger



Am 04.03.20 um 20:04 schrieb Elmar Stellnberger:

Hi folks

   You can now download the indicated program at 
https://www.elstel.org/atea/ and read some documentation at 
https://www.elstel.org/DANE/.


Kind Regards,
Elmar

Am 17.01.20 um 16:52 schrieb Elmar Stellnberger:

Hi Cindy Sue! Hi folks!

   I must confess there is little you can do about missing emails with 
debcheckroot. You can spot rootkits with hindsight but intelligence 
can also break in and go without leaving any trace. What would to my 
mind be necessary for a more secure email communication is a better 
penetration of DANE. Many CAs are known to issue rogue certificates to 
secret services so the public key is the only thing that may be 
trustworthy of a certificate. If that public key is signed and bound 
to a domain with DNSSEC (this is then called DANE) it shall be safe. I 
would guess that email dispatching was safe if encrypted and saved by 
DANE all the way to its target. F.i. it seems likely that intelligence 
just tries to halt email delivery if some suspicious email is in the 
queue until they have assessed what they wanna do about it. And it is 
questionable how those emails which seem to be sent successfully but 
which do not reach their target get lost.


    Something I as an end user can do about the emailing problem is to 
write and send my emails on a secure machine. If I am using webmail or 
an emailing program this requires to preconfigure certificates known 
to be safe and to only allow these. All CAs need to be disabled since 
the average user will never know which CAs issue rogue certificates. 
According to my knowledge any simple web page invocation immediately 
results in a cracked system if it is using a spoofed certificate which 
can not be excluded for any simple web search. Luckily my hoster 
provides DANE for the machines used for email delivery, webmailing and 
my website configuration panel. And I am still using a Debian 8 read 
only stick to boot such a secure system.


    Why the hell Debian 8? Isn`t that insecure? I believe it isn`t as 
long as I only visit these two web pages of my hoster. Unfortunately 
newer versions of Firefox have a special implementation for so called 
HSTS (http strict transport security) certificates. You can not add a 
security exception for such a certificate but you need to configure 
all dependent certification authorities for such a certificate. 
However with the first CA you acknowledge you compromise your system`s 
security. Older versions of Firefox did not have this bug: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1606802


   I am currently looking forward to test which versions of Debian 9 
would work. Firefox from Debian 10 does no more work. If you have good 
luck your webmailing server supports DANE but does not use HSTS. Then 
you can use a current Debian. With Debian 8 you simply need to delete 
libnssckbi.so from libnss3 to disable all default CAs. You can not 
delete them by hand. If you do you need to mark every singleton CA but 
that does not prevent all deleted CAs to reappear a second after you 
have deleted them. That is why you needed to delete the .so. With 
newer versions of Firefox deleting libnssckbi.so does not stay without 
side effects: You can then not acknowledge security exceptions by hand 
any more. I have written a script to do that automatically though and 
I am likely to publish it at https://www.elstel.org/DANE/ in the 
future if sufficient interest is given in the issue. Once I know the 
last good Firefox version I could also approach to resolve the bug 
from above for newer Firefox versions. Unfortunately Dana Keeler has 
given this bug a resolved invalid so that it is unsure whether they 
would accept the bugfix upstreams. According to Dana`s comments the 
bug should in deed be marked as WONTFIX. That would be correct. If you 
like vote or comment for/on this bug.


Elmar


Am 17.01.20 um 14:29 schrieb Cindy Sue Causey:

On 11/27/19, Elmar Stellnberger  wrote:

Am 25.11.19 um 12:35 schrieb Patrick Schleizer:

Yes, forget about NSA and alike. Let's not assume quasi-omnipotent
attackers. That leads to defeatist mindset which isn't productive.

    I would not let myself be defeated easily. Who has thought about
emails in your inbox which are deleted before you can see them? Easily
doable. They would just need to know your password. Or about outgoing
emails which do not reach their target. As far as I have learnt to know
it you can see them in the sent folder

Re: debcheckroot v2.0 released


Hi folks

  You can now download the indicated program at 
https://www.elstel.org/atea/ and read some documentation at 
https://www.elstel.org/DANE/.


Kind Regards,
Elmar

Am 17.01.20 um 16:52 schrieb Elmar Stellnberger:

Hi Cindy Sue! Hi folks!

   I must confess there is little you can do about missing emails with 
debcheckroot. You can spot rootkits with hindsight but intelligence can 
also break in and go without leaving any trace. What would to my mind be 
necessary for a more secure email communication is a better penetration 
of DANE. Many CAs are known to issue rogue certificates to secret 
services so the public key is the only thing that may be trustworthy of 
a certificate. If that public key is signed and bound to a domain with 
DNSSEC (this is then called DANE) it shall be safe. I would guess that 
email dispatching was safe if encrypted and saved by DANE all the way to 
its target. F.i. it seems likely that intelligence just tries to halt 
email delivery if some suspicious email is in the queue until they have 
assessed what they wanna do about it. And it is questionable how those 
emails which seem to be sent successfully but which do not reach their 
target get lost.


    Something I as an end user can do about the emailing problem is to 
write and send my emails on a secure machine. If I am using webmail or 
an emailing program this requires to preconfigure certificates known to 
be safe and to only allow these. All CAs need to be disabled since the 
average user will never know which CAs issue rogue certificates. 
According to my knowledge any simple web page invocation immediately 
results in a cracked system if it is using a spoofed certificate which 
can not be excluded for any simple web search. Luckily my hoster 
provides DANE for the machines used for email delivery, webmailing and 
my website configuration panel. And I am still using a Debian 8 read 
only stick to boot such a secure system.


    Why the hell Debian 8? Isn`t that insecure? I believe it isn`t as 
long as I only visit these two web pages of my hoster. Unfortunately 
newer versions of Firefox have a special implementation for so called 
HSTS (http strict transport security) certificates. You can not add a 
security exception for such a certificate but you need to configure all 
dependent certification authorities for such a certificate. However with 
the first CA you acknowledge you compromise your system`s security. 
Older versions of Firefox did not have this bug: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1606802


   I am currently looking forward to test which versions of Debian 9 
would work. Firefox from Debian 10 does no more work. If you have good 
luck your webmailing server supports DANE but does not use HSTS. Then 
you can use a current Debian. With Debian 8 you simply need to delete 
libnssckbi.so from libnss3 to disable all default CAs. You can not 
delete them by hand. If you do you need to mark every singleton CA but 
that does not prevent all deleted CAs to reappear a second after you 
have deleted them. That is why you needed to delete the .so. With newer 
versions of Firefox deleting libnssckbi.so does not stay without side 
effects: You can then not acknowledge security exceptions by hand any 
more. I have written a script to do that automatically though and I am 
likely to publish it at https://www.elstel.org/DANE/ in the future if 
sufficient interest is given in the issue. Once I know the last good 
Firefox version I could also approach to resolve the bug from above for 
newer Firefox versions. Unfortunately Dana Keeler has given this bug a 
resolved invalid so that it is unsure whether they would accept the 
bugfix upstreams. According to Dana`s comments the bug should in deed be 
marked as WONTFIX. That would be correct. If you like vote or comment 
for/on this bug.


Elmar


Am 17.01.20 um 14:29 schrieb Cindy Sue Causey:

On 11/27/19, Elmar Stellnberger  wrote:

Am 25.11.19 um 12:35 schrieb Patrick Schleizer:

Yes, forget about NSA and alike. Let's not assume quasi-omnipotent
attackers. That leads to defeatist mindset which isn't productive.

    I would not let myself be defeated easily. Who has thought about
emails in your inbox which are deleted before you can see them? Easily
doable. They would just need to know your password. Or about outgoing
emails which do not reach their target. As far as I have learnt to know
it you can see them in the sent folder but they never appear on the
other side, not even in the spam-box. The worse thing is however if
someone wants to contact you and you do not even know about it, the
other one just thinking you did not reply.


There have been two situations that, no, I can't name just this
second, so this is anecdotal material *until I stumble back upon* the
very real cases, BUT...

Twice in the last maybe six months, there has been chatter about the
receiving end's server(s) stopping the flow of incoming emails for
unknown reasons. The occurrences

Re: debcheckroot v2.0 released

2020-01-17 Thread Elmar Stellnberger

The programs which I use for secure DANE web browsing should be uploaded 
at: https://www.elstel.org/DANE/


documentation follows later


Am 17.01.20 um 16:52 schrieb Elmar Stellnberger:

Hi Cindy Sue! Hi folks!

  I must confess there is little you can do about missing emails with 
debcheckroot. You can spot rootkits with hindsight but intelligence 
can also break in and go without leaving any trace. What would to my 
mind be necessary for a more secure email communication is a better 
penetration of DANE. Many CAs are known to issue rogue certificates to 
secret services so the public key is the only thing that may be 
trustworthy of a certificate. If that public key is signed and bound 
to a domain with DNSSEC (this is then called DANE) it shall be safe. I 
would guess that email dispatching was safe if encrypted and saved by 
DANE all the way to its target. F.i. it seems likely that intelligence 
just tries to halt email delivery if some suspicious email is in the 
queue until they have assessed what they wanna do about it. And it is 
questionable how those emails which seem to be sent successfully but 
which do not reach their target get lost.


   Something I as an end user can do about the emailing problem is to 
write and send my emails on a secure machine. If I am using webmail or 
an emailing program this requires to preconfigure certificates known 
to be safe and to only allow these. All CAs need to be disabled since 
the average user will never know which CAs issue rogue certificates. 
According to my knowledge any simple web page invocation immediately 
results in a cracked system if it is using a spoofed certificate which 
can not be excluded for any simple web search. Luckily my hoster 
provides DANE for the machines used for email delivery, webmailing and 
my website configuration panel. And I am still using a Debian 8 read 
only stick to boot such a secure system.


   Why the hell Debian 8? Isn`t that insecure? I believe it isn`t as 
long as I only visit these two web pages of my hoster. Unfortunately 
newer versions of Firefox have a special implementation for so called 
HSTS (http strict transport security) certificates. You can not add a 
security exception for such a certificate but you need to configure 
all dependent certification authorities for such a certificate. 
However with the first CA you acknowledge you compromise your system`s 
security. Older versions of Firefox did not have this bug: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1606802


  I am currently looking forward to test which versions of Debian 9 
would work. Firefox from Debian 10 does no more work. If you have good 
luck your webmailing server supports DANE but does not use HSTS. Then 
you can use a current Debian. With Debian 8 you simply need to delete 
libnssckbi.so from libnss3 to disable all default CAs. You can not 
delete them by hand. If you do you need to mark every singleton CA but 
that does not prevent all deleted CAs to reappear a second after you 
have deleted them. That is why you needed to delete the .so. With 
newer versions of Firefox deleting libnssckbi.so does not stay without 
side effects: You can then not acknowledge security exceptions by hand 
any more. I have written a script to do that automatically though and 
I am likely to publish it at https://www.elstel.org/DANE/ in the 
future if sufficient interest is given in the issue. Once I know the 
last good Firefox version I could also approach to resolve the bug 
from above for newer Firefox versions. Unfortunately Dana Keeler has 
given this bug a resolved invalid so that it is unsure whether they 
would accept the bugfix upstreams. According to Dana`s comments the 
bug should in deed be marked as WONTFIX. That would be correct. If you 
like vote or comment for/on this bug.


Elmar

Re: debcheckroot v2.0 released

2020-01-17 Thread Elmar Stellnberger


Hi Cindy Sue! Hi folks!

  I must confess there is little you can do about missing emails with 
debcheckroot. You can spot rootkits with hindsight but intelligence can 
also break in and go without leaving any trace. What would to my mind be 
necessary for a more secure email communication is a better penetration 
of DANE. Many CAs are known to issue rogue certificates to secret 
services so the public key is the only thing that may be trustworthy of 
a certificate. If that public key is signed and bound to a domain with 
DNSSEC (this is then called DANE) it shall be safe. I would guess that 
email dispatching was safe if encrypted and saved by DANE all the way to 
its target. F.i. it seems likely that intelligence just tries to halt 
email delivery if some suspicious email is in the queue until they have 
assessed what they wanna do about it. And it is questionable how those 
emails which seem to be sent successfully but which do not reach their 
target get lost.


   Something I as an end user can do about the emailing problem is to 
write and send my emails on a secure machine. If I am using webmail or 
an emailing program this requires to preconfigure certificates known to 
be safe and to only allow these. All CAs need to be disabled since the 
average user will never know which CAs issue rogue certificates. 
According to my knowledge any simple web page invocation immediately 
results in a cracked system if it is using a spoofed certificate which 
can not be excluded for any simple web search. Luckily my hoster 
provides DANE for the machines used for email delivery, webmailing and 
my website configuration panel. And I am still using a Debian 8 read 
only stick to boot such a secure system.


   Why the hell Debian 8? Isn`t that insecure? I believe it isn`t as 
long as I only visit these two web pages of my hoster. Unfortunately 
newer versions of Firefox have a special implementation for so called 
HSTS (http strict transport security) certificates. You can not add a 
security exception for such a certificate but you need to configure all 
dependent certification authorities for such a certificate. However with 
the first CA you acknowledge you compromise your system`s security. 
Older versions of Firefox did not have this bug: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1606802


  I am currently looking forward to test which versions of Debian 9 
would work. Firefox from Debian 10 does no more work. If you have good 
luck your webmailing server supports DANE but does not use HSTS. Then 
you can use a current Debian. With Debian 8 you simply need to delete 
libnssckbi.so from libnss3 to disable all default CAs. You can not 
delete them by hand. If you do you need to mark every singleton CA but 
that does not prevent all deleted CAs to reappear a second after you 
have deleted them. That is why you needed to delete the .so. With newer 
versions of Firefox deleting libnssckbi.so does not stay without side 
effects: You can then not acknowledge security exceptions by hand any 
more. I have written a script to do that automatically though and I am 
likely to publish it at https://www.elstel.org/DANE/ in the future if 
sufficient interest is given in the issue. Once I know the last good 
Firefox version I could also approach to resolve the bug from above for 
newer Firefox versions. Unfortunately Dana Keeler has given this bug a 
resolved invalid so that it is unsure whether they would accept the 
bugfix upstreams. According to Dana`s comments the bug should in deed be 
marked as WONTFIX. That would be correct. If you like vote or comment 
for/on this bug.


Elmar


Am 17.01.20 um 14:29 schrieb Cindy Sue Causey:

On 11/27/19, Elmar Stellnberger  wrote:

Am 25.11.19 um 12:35 schrieb Patrick Schleizer:

Yes, forget about NSA and alike. Let's not assume quasi-omnipotent
attackers. That leads to defeatist mindset which isn't productive.

I would not let myself be defeated easily. Who has thought about
emails in your inbox which are deleted before you can see them? Easily
doable. They would just need to know your password. Or about outgoing
emails which do not reach their target. As far as I have learnt to know
it you can see them in the sent folder but they never appear on the
other side, not even in the spam-box. The worse thing is however if
someone wants to contact you and you do not even know about it, the
other one just thinking you did not reply.


There have been two situations that, no, I can't name just this
second, so this is anecdotal material *until I stumble back upon* the
very real cases, BUT...

Twice in the last maybe six months, there has been chatter about the
receiving end's server(s) stopping the flow of incoming emails for
unknown reasons. The occurrences were purely "glitches", NOT on
purpose. It was either machine failure or accidentally
Human-instigated mis-code or something that provoked the situations.

End users found out when a sudden flood of sometimes OLD emai

Re: Why no security support for binutils? What to do about it?

2020-01-01 Thread Elmar Stellnberger




Am 01.01.20 um 10:48 schrieb PJ:

Maybe ultimately one needs monitors and diff-machines built in hardware
(and more or less by oneself).

If compilers can be subverted, so can assemblers.


It would be really worthwhile to have a decompiler!

It is not assemblers that are subverted but machine instructions not 
executing the way they were specified.





If intelligence is everywhere, so is intel.

If controlling people is everywhere, so is manipulation.

If exercising power goes beyond oneself, so does one's own corruption.


I am not corrupt. Overall money gives little motivation to me. Attaining 
freedom does!





The only real solution is in one's own efforts to love, and thus to
become one with The One.

Those who think they are already there are just blind for what is beyond
their perception.

Re: Why no security support for binutils? What to do about it?

2020-01-01 Thread Elmar Stellnberger




Am 01.01.20 um 03:14 schrieb Paul Wise:

On Tue, Dec 31, 2019 at 9:47 AM Florian Weimer wrote:


BFD and binutils have not been designed to process untrusted data.
Usually, this does not matter at all.  For example, no security
boundary is crossed when linking object files that have been just been
compiled.

There are definitely situations where vulnerabilities in binutils
(mostly objdump) are important and a security boundary could be
crossed, for example; running lintian on ftp-master,
malware reverse engineering


  Up to now I did not see any notable effort to support malware reverse 
engineering under Linux. The only program I knew was boomerang for 
decompiling malware but it seems to be unsupported since long. I would 
really be in need of such software since I have plenty of images of 
rootkitted installations and tampered BIOS images (f.i. one does not 
boot via USB and does not allow BIOS updates; you can not get rid of it 
unless you flash the BIOS chip of you mainboard externally).




and inspection of binaries for hardening features.

Re: debcheckroot v2.0 released

2019-12-10 Thread Elmar Stellnberger




Am 25.11.19 um 17:52 schrieb Elmar Stellnberger:

Not using apt/dpkg comes at the expense of not being able to fully
verify the whole system. What if there are outdated packages on the
system which aren't available from anymore from repository? Using
snapshot.debian.org?


I have just extended debcheckroot to also support file repos. Now it 
can check 100% of the packages I have installed. That was necessary 
because f.i. the printer driver is vendor specific and can not be 
fetched from an online repo. I will publish that as debcheckroot v2.2 
soon. Outdated packages are a problem though; I have supposed that 
Debian would maintain sha256sums for packages not available online any 
more. However I do not see any good possibility to resolve this 
without support from the distributors. However I am not sure whether 
outdated updates would still be available on snapshot.debian.org; I 
would not believe so, though perhaps anyone else reading this list 
could help us. If it is not about updates but about singleton packages 
one could download specific packages from snapshot by hand if you 
really come across having installed such a package.


  If debcheckroot can not find many packages that may point to an 
intentionally altered package database and thus to a possible infection 
of your system. I have seen many ways how to avoid scrutiny by 
debcheckroot in the past and this may just be an easy way to achieve 
this. Remember that with a freshly updated system + packages you 
downloaded manually, 100% of all packages should be verifiable. I do 
think of the theoretically constructed case that a package is still 
installed that is no more available via the update repo as rather 
improbable as normally the base version of all packages is available in 
the base repo. If a newer version is available in the update repo the 
update should have been installed as well.

Re: debcheckroot v2.0 released

2019-11-27 Thread Elmar Stellnberger




Am 25.11.19 um 12:35 schrieb Patrick Schleizer:

Yes, forget about NSA and alike. Let's not assume quasi-omnipotent
attackers. That leads to defeatist mindset which isn't productive.


  I would not let myself be defeated easily. Who has thought about 
emails in your inbox which are deleted before you can see them? Easily 
doable. They would just need to know your password. Or about outgoing 
emails which do not reach their target. As far as I have learnt to know 
it you can see them in the sent folder but they never appear on the 
other side, not even in the spam-box. The worse thing is however if 
someone wants to contact you and you do not even know about it, the 
other one just thinking you did not reply.


  The NSA & 5 Eyes are not just the most omni-potent but also the 
most-ubiquitous attackers so it should pay off trying to shield against 
them. There are as much unsuspecting users out there that you can not 
count. Shouldn´t we motivate them to check their machines? Sometimes it 
can be as easy as to sport executables in /bin which do not belong there 
and can normally be found in /usr/bin.

Re: debcheckroot v2.0 released

2019-11-25 Thread Elmar Stellnberger


Am 21.11.19 um 13:59 schrieb Odo Poppinger:


Am 20.11.19 um 12:29 schrieb Elmar Stellnberger:
debcheckroot is targeted at technically experienced users. No way to 
hunt rootkits authored by the NSA otherwise. You have to be a tough 
user to take this challenge! Well you can of course also use it for 
other kinds of rootkits by other governments or from criminals but 
interpreting the results requires some kind of knowledge about a 
Linux system. You need to know what the kernel is, what an initrd is, 
what you can find under /bin, /usr/bin, /sbin and /usr/sbin.


The tool has primarily been written against 5 eyes rootkits but I 
think it is still missing some features to take this challenge. f.i. 
it should be possible to unpack *.deb-s in an own boot run, separate 
from downloading and verification. That would shield against attacks 
targeted at the unpacking which affect the very system debcheckroot 
runs on. Supporting file only repos for customly downloaded and 
installed packages like my printer driver would also be an issue.


Why not simply use sha256 - lists as can already be used and generated 
with debcheckroot (as far as I have seen)? That would resolve the 
problem of a possible infection of the host system running 
debcheckroot because there are no archives that need to be unpacked 
when using plain sha256 file lists. We would only need some official 
support by Debian for this, i.e. someone who creates/updates these 
sha256 lists every time the updates repository is updated and puts 
them online in a publicly known place.


  You can avoid an infection of the host system by generating 
sha256sums in one boot run with -t my.shalis --no-verify and use this on 
another boot with -u my.shalis --only --offline. I have now documented 
these options on the official webpage 
https://www.elstel.org/debcheckroot/. Options to download on a separate 
machine are also documented. Besides this I have revised the 
documentation as a whole so it may be worth reading it once more.


  Today in the evening I have released debcheckroot-v2.2. You may view 
all the updates at 
https://www.elstel.org/ViewRSS.php?ctgs=programs=en or via 
https://www.elstel.org/ViewRSS.php?srcs=debcheckroot=en

Re: debcheckroot v2.0 released

2019-11-25 Thread Elmar Stellnberger




Am 25.11.19 um 12:35 schrieb Patrick Schleizer:

How often did you see initrd being infected?


recently only once. So the attackers may change their vector; they have 
already done so multiple times.



Not using apt/dpkg comes at the expense of not being able to fully
verify the whole system. What if there are outdated packages on the
system which aren't available from anymore from repository? Using
snapshot.debian.org?


I have just extended debcheckroot to also support file repos. Now it can 
check 100% of the packages I have installed. That was necessary because 
f.i. the printer driver is vendor specific and can not be fetched from 
an online repo. I will publish that as debcheckroot v2.2 soon. Outdated 
packages are a problem though; I have supposed that Debian would 
maintain sha256sums for packages not available online any more. However 
I do not see any good possibility to resolve this without support from 
the distributors. However I am not sure whether outdated updates would 
still be available on snapshot.debian.org; I would not believe so, 
though perhaps anyone else reading this list could help us. If it is not 
about updates but about singleton packages one could download specific 
packages from snapshot by hand if you really come across having 
installed such a package.




Also, for quickly repeatable verification it would be best to prepare as
much as possible in background / during upgrade. Other tasks can be done
at the same time. Then booting from read-only to debcheckroot purposes
could safe a lot time. The less time it needs, the more it gets within
reach to automate the process without sacrificing much boot time.

Also by not using apt/dpkg, any packages downloaded would have to be gpg
verified manually.

I also don't see debcheckroot make use of gpg signature verification of
downloaded files?

Reinventing apt is difficult. See these attack on package managers:

https://www2.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html

Package metadata could be outdated. Downloaded package contents could be
malicious or altered to pass verification.


Yes, tor is no ultimate remedy to this. As long as there are little 
downloads anonymity may be compromised. The best way to shield against 
such attacks may be to first generate sha256sum lists in a singleton 
boot and then later on use them in another boot so that no malware from 
unpacking packages can persist in memory. However that is no remedy to 
altered package content. The only way I know to avoid this is to only 
install from blue ray media without using online updates.



That article https://www.elstel.org/software/GnuPG-usage.html.en starts
with "How to use GnuPG securely". That isn't the best way to communicate
"Key signatures are not trustworthy in general" which is a pretty broad
claim.

If "Key signatures are not trustworthy in general" then all apt package
downloads could be considered compromised since APT relies on gnupg for
verification. With that was true, and with mindset, and that being
unfixable, we could as well as give up.


Yes, that is what I presume. apt can install compromised updates. I know 
this is at least an attack vector for Windows. To repeat it I would at 
least doubt if not presume about any key which is stored online that it 
is compromised. Most times people connect with ssh to such machines and 
have a local certificate on the computer from which they connect. The 
certificate can be copied and the password will be keylogged. Only a 
very few people employ security strategies like switching keyboard and 
monitor to a computer where you do not web-browse or email. I have 
devices for that but most people don´t and as long as the distributors 
do not advertise it I presume that they do not follow such a strategy. 
Finally it would still be possible to get the key by physical access to 
that computer. I would also believe that for a distro like Debian this 
would pay of for intelligence services.


To me personally I don´t have a defeatist mindset even not if the 
NSA/CIA or similar services are attacking me. They have once deleted the 
partition table on a computer used only offline to analyse some rootkit. 
Those who hack me also have physical access to my computers. There is no 
way for a defeatist mindset though as I can not let my human rights 
including that to live be violated.





To a rootkit hunter which laymen can use it's a long way to go. Some

debcheckroot is targeted at technically experienced users.


That's sad. Understood.


No it isn´t. People who care about security need to acquaint themselves 
with some basic facts on how the system they use is working. As it is 
Linux all the information should be available for the interested user. - 
and people do not only need to do so for use of debcheckroot.



No way to
hunt rootkits authored by the NSA otherwise.


Yes, forget about NSA and alike. Let's not assume quasi-omnipotent
attackers. That leads to

Re: debcheckroot v2.0 released

2019-11-21 Thread Elmar Stellnberger



Am 21.11.19 um 13:59 schrieb Odo Poppinger:

Am 20.11.19 um 12:29 schrieb Elmar Stellnberger:
debcheckroot is targeted at technically experienced users. No way to 
hunt rootkits authored by the NSA otherwise. You have to be a tough 
user to take this challenge! Well you can of course also use it for 
other kinds of rootkits by other governments or from criminals but 
interpreting the results requires some kind of knowledge about a 
Linux system. You need to know what the kernel is, what an initrd is, 
what you can find under /bin, /usr/bin, /sbin and /usr/sbin.


The tool has primarily been written against 5 eyes rootkits but I 
think it is still missing some features to take this challenge. f.i. 
it should be possible to unpack *.deb-s in an own boot run, separate 
from downloading and verification. That would shield against attacks 
targeted at the unpacking which affect the very system debcheckroot 
runs on. Supporting file only repos for customly downloaded and 
installed packages like my printer driver would also be an issue.


Why not simply use sha256 - lists as can already be used and generated 
with debcheckroot (as far as I have seen)? That would resolve the 
problem of a possible infection of the host system running 
debcheckroot because there are no archives that need to be unpacked 
when using plain sha256 file lists. We would only need some official 
support by Debian for this, i.e. someone who creates/updates these 
sha256 lists every time the updates repository is updated and puts 
them online in a publicly known place.


Yes, that is a very good idea!:

* debcheckroot with sha256-lists is considerably faster because it does 
not need to download and unpack all packages


* unknown/forgotten packages of elder versions could still be checked 
because the sha256sums are not forgotten


* You can generate sha256sums incrementally with debcheckroot, i.e. 
extend an existing list only for the new packages

Re: debcheckroot v2.0 released

2019-11-20 Thread Elmar Stellnberger




Am 19.11.19 um 13:29 schrieb Patrick Schleizer:

Anyone using this yet?

I would speculate, not many are using it. It needs step by step
instructions. Otherwise, most users are lost at hello.


Well, I have a couple of downloads every day, the more serious ones with 
wget.





Things debcheckroot does not check at the moment are the initrd and

the MBR (master boot record). You may unpack the initrd by hand and
check the files contained there against a sha256sum list generated by
debcheckroot. The MBR can first be backuped by confinedrv/diskutils.
Then reinstall it with Grub from a fresh boot CD and look if the boot
sector has altered. Under normal circumstances Grub would install the
exactly same code into the MBR.


I guess "nobody" is going to do that. Sounds complicated. And I am


The issue is that you do not need to check the initrd in deed under 
normal circumstances. If the initrd is infected so will be 
/sbin/mkinitramfs. I have never seen the initrd being infected alone as 
this would need to be updated on every new kernel configuration update 
like when you install firmware.



[tor-dev] First-time tails/tor user feedback

https://lists.torproject.org/pipermail/tor-dev/2012-April/003472.html

Eliminating Stop-Points in the Installation and Use ofAnonymity Systems:
a Usability Evaluation of the Tor Browser Bundle

https://petsymposium.org/2012/papers/hotpets12-1-usability.pdf


I would also suggest a different design / additional feature. Rather
than requiring a network connection or DVD, could you add a feature
please similar to "apt-file" or "command-not-found"? What I mean by that:

These tools download a cache while the system is running. debcheckroot
could download/generate/prepare all the sha256 files on the disk. Yes,
within the running system. Don't worry about verifying integrity of
these files just yet. That will be answered later. Yes, these sha256
files could be maliciously altered. But that is something you can check
later at debcheckroot runtime.


What you suggest here does not make sense to me. If you have to check 
 these sha256 lists later on it is the same work as if you do 
not use them.



Generating the (sha256) files required for later verification could be
done using an apt or dpkg hook.


No, it is a feature of the tool that it does not require the dpkg 
infrastructure. - an important one. I have even successfully verified an 
old Debian6 installation with debcheckroot-v2.0. - no binaries required, 
only plain Python available almost everywhere.



Then, later when debcheckroot runs, it would rely on these files. But to
check that these files haven't been altered, it could check them against
repository signing keys. So debcheckroot would need a bit root of trust
built-in or better configurable. For example, it could be sufficient to
point debcheckroot at clean Debian repository signing keys. These would
then be used to check the sha256 files.


Key signatures are not trustworthy in general. I have argued this a 100 
times; see also https://www.elstel.org/software/GnuPG-usage.html.en



The advantage of this would be that debcheckroot can be run from Live
USD or Live DVD. Offline. No need for a network connection since all
files to be verified would already be prepared.


debcheckroot can already perfectly run offline from the live cd of any 
distribution. I think you didn´t read the docs.



To a rootkit hunter which laymen can use it's a long way to go. Some


debcheckroot is targeted at technically experienced users. No way to 
hunt rootkits authored by the NSA otherwise. You have to be a tough user 
to take this challenge! Well you can of course also use it for other 
kinds of rootkits by other governments or from criminals but 
interpreting the results requires some kind of knowledge about a Linux 
system. You need to know what the kernel is, what an initrd is, what you 
can find under /bin, /usr/bin, /sbin and /usr/sbin.


The tool has primarily been written against 5 eyes rootkits but I think 
it is still missing some features to take this challenge. f.i. it should 
be possible to unpack *.deb-s in an own boot run, separate from 
downloading and verification. That would shield against attacks targeted 
at the unpacking which affect the very system debcheckroot runs on. 
Supporting file only repos for customly downloaded and installed 
packages like my printer driver would also be an issue.


Once, the more people are using debcheckroot via Tails the harder it 
will get for intelligence to spoof these downloads. Effectiveness of 
debcheckroot is also an issue of a critical mass of users who apply the 
tool at least from time to time.


Most people do not take the threat posed by rootkits authored by western 
intelligence serious, though. I believe only a very few users are using 
Tails with --download-only as this was not well supported with 
debcheckroot-v2.0 but nobody had complained. It would have been possible 
to download via Tor using deblive linked from

Re: Verified Boot, Secure Boot, dm-verity, debcheckroot

2019-11-16 Thread Elmar Stellnberger





There are tools that can help with checking all files on the hard drive
such as `debsums`. However, while `debsums` is more popular, it is
unsuitable.

Quote https://www.elstel.org/debcheckroot/

...
During development of Verifiable Builds experiences were made with
verification of MBR, VBR, bootloader, partition table, kernel and
initrd. Source code was created to analyze such files.

https://www.whonix.org/wiki/Verifiable_Builds


verifying the BIOS/UEFI:

Most of the computers I have support flashrom. Either I have added 
support on my own or I have bought machines that were known to support it.
If you take a malware image with debcheckroot you should possibly also 
add an image of your BIOS. I can report about the following discoveries:

Lately I have taken multiple BIOS images on a P5P41TUSB3, ASUS board:
* naturally that board does not boot from USB3
* some time I have found it to boot from sdcard but only when a certain 
hard disk was attached via usb3 ob boot time, the boot sector of that 
hard disk was blanked (containing zeroes).
  This discovery would strongly indicate that the BIOS was manipulated 
and that some boot code was fetched likely from the intermediate gaps in 
the partition table of that USB hard disk used for downloads with Tails
* some time later it did boot from any usb3 slot also from the usb3 
sdcard reader no matter what hard disk was attached

* now, since last week it does no more boot from usb3
If anyone wants to have these BIOS images I could upload them somewhere.
It is a question on how to determine if possibly malicious changes have 
been applied to a bios image.
I have used bindiff (https://www.elstel.org/qemu/) to list the number of 
bytes that differ between BIOS images.
- about 70 bytes differed between any two boots, even if you do not 
enter the BIOS settings
- after flashing a new BIOS with ASUS EZ+Flash, a BIOS internal flash 
utility a little more bytes differed, but not that many
- when leaving the computer alone for half a week far more bytes 
differed + the boot behaviour as described above

Re: Verified Boot, Secure Boot, dm-verity, debcheckroot

2019-11-16 Thread Elmar Stellnberger





There are tools that can help with checking all files on the hard drive
such as `debsums`. However, while `debsums` is more popular, it is
unsuitable.

Quote https://www.elstel.org/debcheckroot/

...
During development of Verifiable Builds experiences were made with
verification of MBR, VBR, bootloader, partition table, kernel and
initrd. Source code was created to analyze such files.

https://www.whonix.org/wiki/Verifiable_Builds


regarding verifiable builds with gcc, flex, bison, etc.:

I have recompiled some of my self-written source code lately with gcc 
and the executables and object files were exactly the same.

So when is a build now deterministic?
I would be interested in comparing compilation results of the kernel 
sources. Does anyone know what needs to be met for these to be 
deterministic?
From what Debian/gcc version on are deterministic builds supported? I 
remember this was a well discussed issue some time ago.
I have a self compiled kernel under Debian8. I guess that one would not 
have been built deterministic?
It is an issue to verify a self compiled kernel (I need to use the patch 
from https://www.elstel.org/software/hunt-for-4K-UHD-2160p.html.en).

debcheckroot v2.0 released

2019-11-15 Thread Elmar Stellnberger


Dear readers of debian-security

  I have just released debcheckroot-v2.0: 
https://www.elstel.org/debcheckroot/


The new tool can be used to check a Debian installation also against 
previously unknown rootkits. It has many improvements towards 
debcheckroot-v1.0:


# usage of direct comparison or creation and usage of sha-256 lists 
instead of the unsafe md5sums provided in the package header
# allow usage of multiple changeable media: i.e. DVD & BD-SL verification 
rather than just BD-DL verification

# testing of symbolic links, of user, group and file-mode
# scanning the home directory for odd filenames that contain control 
characters, on request: listing all hidden binary files in the home 
directory
# download only mode + shuffling of download order for package download 
via Tails/Tor and subsequent offline verification
# use of Python3 instead of Perl with built in support for tar, xzip, gzip 
and bzip2; no more external helper programs required, works from any 
live cd!


Finally debcheckroot-v1.0 did no more work with current versions of 
Debian as Debian now uses xzip instead of gzip. The new program supports 
any of xzip, gzip and bz2 for compression of the data.tar.xz and the 
controls .tar.xz inside the .deb ar-archive. Files are merely unpacked 
in memory so debcheckroot keeps being quite efficient.


I would be happy to discuss the new release here or to assist anyone who 
wants to test the new tool!


Regards,
Elmar

Re: about older security advisories

2019-10-29 Thread Elmar Stellnberger


I would not rely on the wayback machine to preserve old content.

Why don´t you host it at debian? web content should not need much space.

Why shall the old content not be usable any more?


Am 28.10.19 um 22:45 schrieb Moritz Mühlenhoff:

Thomas Lange  schrieb:

On Mon, 28 Oct 2019 17:31:22 +, krishna  said:

 > i am going through older security advisories at webpage [z]. i have found some links are dead, 
etc.. some security advisory does not contain "More information" and "Security database 
references". example : 1&2.

Hi leela,

this is the correct location for asking those things.
But IMHO it's not worth to fix these very old web pages.

Agreed, if anyone really wants to follow the old links, they're
also most certainly in the Wayback Machine as well.

Cheers,
 Moritz

Re: Have I caught a firmware attack in the act? Or am I just paranoid?

2019-08-23 Thread Elmar Stellnberger

The key question about it is how the archive keys are handled. I believe 
that keeping such a key offline would be a whole lot of work. It would 
perhaps also help to have it on a gpg-Smartcard.


Am 23.08.19 um 09:10 schrieb Rebecca N. Palmer:

On 17/08/2019 12:18, Elmar Stellnberger wrote:

to be safe the key handling policy needs to be offline enforced


There have been various attempts to encourage / simplify the use of 
offline keys, but it isn't currently required in Debian, and some of 
them only suggest keeping the master key (not the signing subkey, 
which is enough to upload packages) offline.


(non-trust warning: these are anyone-can-post areas)
https://wiki.debian.org/GnuPG
https://wiki.debian.org/OpenPGP/CleanRoomLiveEnvironment
https://lists.debian.org/debian-project/2017/08/threads.html#00011

Also, firmware attacks can reach offline keys.

However:

Intelligence can not spoof all downloads - there is always a certain 
percentage of downloads which get the original data; i.e. they only 
spoof the download if they know who is downloading.


Individual developers' keys are used to protect uploads (from that 
developer to the Debian archive), but downloads (from that archive to 
a user, i.e. apt upgrade/install) are protected by a tree of hashes 
signed by the archive's own key (see /var/lib/apt/lists).


Hence, stealing an individual developer's key doesn't let an attacker 
target specific people; it does let them upload as that developer, but 
if they do, *everyone* sees their version of that package.  As you 
note, this makes them more likely to be caught.


To get a malware package to only a specific person, they would need 
either a stolen *archive* key, or a bug/backdoor in apt that makes it 
accept signatures it shouldn't.


Proposal to keep a log of the official hashes, which would allow the 
target of such an attack to prove it was an attack:
https://debconf19.debconf.org/talks/66-software-transparency-improving-package-manager-security/

Re: Have I caught a firmware attack in the act? Or am I just paranoid?

2019-08-17 Thread Elmar Stellnberger






Read only switches are a security feature because you can read the 
content without the fear that it may be altered.[...] The read-only 
switch makes it as safe as a read only burnt dvd.


The physical read-only switch on SD cards isn't: it's enforced at 
software level, not hardware level.


That is only half of the truth. If you have an SDcard - USB adapter the 
adapter is responsible for doing the check and the adapter is hardware. 
If you mean that the SDCard itself enforces the check then this is of 
course not the case.




https://en.wikipedia.org/wiki/SD_card#Card_security

Downloads can and often are impersonated if you do not use tor so 
that you will be shipped the malwared-packages for comparence instead 
of the original ones.


apt (by default) won't install packages with a bad signature: are you 
claiming to have seen fake packages _with a valid signature_, or are 
you referring to downloads of something other than Debian packages?


(I haven't read your links: as I don't have proof of who you are, 
doing so would itself be a security risk.)


gpg signatures of packages are least trustworthy since the NSA has a 
private key stealing programme. Never trust a signature as long as you 
do not know about the key handling policy - and to be safe the key 
handling policy needs to be offline enforced like described here (I 
would suggest that you trust my web page too if you trust in what I am 
saying):


https://www.elstel.org/software/GnuPG-usage.html.en

  Most people do not enforce secure offline storage of secret keys - 
they encrypt on unsafe online computers and they do not secure the data 
carrier where the secret key is stored. If you have read my previous 
posts you know that both conditions need to be met in order to avoid the 
secret key to be stolen. You need to check the sha-s at least via tor 
(if you do not have all the original packages available on blue ray 
media). Intelligence can not spoof all downloads - there is always a 
certain percentage of downloads which get the original data; i.e. they 
only spoof the download if they know who is downloading.

Re: Have I caught a firmware attack in the act? Or am I just paranoid?



Another potential home for this script is tiger, which also currently 
has an MD5-only checker:


https://sources.debian.org/src/tiger/1:3.2.4%7Erc1-1/systems/Linux/2/deb_checkmd5sums/ 



It may be more probable that they simply infect a hidden file in your 
home directory[...]
   I would presume that you have booted from DVD when checking your 
installation since it does not make sense to check from within an 
infected system. That would be going to fail in almost 100% of the 
cases.


This check was done from within the system (it was never intended to 
be a perfect test - as you note, it can be evaded by infecting a 
non-package-owned file), but my script can also do checking from a DVD 
boot.


  An infected system will also alter the md5sum utility so that it will 
return the md5 of the pristine file instead of the altered one which is 
actually on disk (I have already seen that). Concerning your program I 
have seen that it uses /var/lib/dpkg/info/$2.md5sums. This is inherently 
unsafe because an attacker can simply alter this file alongside with all 
the other altered file. Anyone knows about this file and if I logged in 
via ssh an did some manual cracking then I also replaced the md5-s in 
that file with sed -i.


  Nonetheless manual sha512-lists are generally more secure than tools 
just checking files in the packages like debcheckroot because they also 
record files that are not in the installation database as well as files 
auto-generated/altered on installation by installation scripts. You can 
create such an sha512-list after securely offline-installing and put it 
on an sdcard which you take always with you. I like sdcards because they 
have a read only switch and are very small and flat so that you can 
easily take them with you. Read only switches are a security feature 
because you can read the content without the fear that it may be 
altered. Of course you can not easily install new packages then. That 
requires you checking all the sha512s via a clean boot medium. After 
that you can boot into the system, install new packages and update the 
sha512s. I also take the boot media with me where the dvd images reside 
on sdcards bootable via USB-sdcard adapter. The read-only switch makes 
it as safe as a read only burnt dvd.


  Concerning debcheckroot I had planned to make it support mounting 
different install-dvds/bds. At the moment it only works with a singleton 
install blue ray. Installing from blue ray or dvd is an additional 
security measure you can take to spot malware. I would not have been 
able to spot the rootkit I had talked about in my last mail in 
Brasileia, Brazil (Cobija, Bolivia) if I had decided to install online 
updates because then fetching the updated packages for the tool 
(debcheckroot supports this) would have been much more complicated. 
Downloads can and often are impersonated if you do not use tor so that 
you will be shipped the malwared-packages for comparence instead of the 
original ones. So always use tor with debcheckroot if you do not have 
all the packages available offline. To come back to the rootkit spotted 
in South America I had the fortune to spot it only because I could 
compare all files 1:1 which was only possible because I did not need 
online repositories to install the clean image of the distro.


  Here is again the reference for debcheckroot:

https://www.elstel.org/debcheckroot/|
|

Re: Have I caught a firmware attack in the act? Or am I just paranoid?




Am 15.08.19 um 22:57 schrieb Rebecca N. Palmer:


That would suggest it's not them, as the obvious reason to target me 
is to trick me into uploading malware.


If that is the case you would have to take hellish care. I have read 
articles of the compiler as attack vector, i.e. an altered compiler can 
produce infected programs even if the source code is clean. You may need 
to compile either offline or at least on a computer where you do not 
open a web browser or email program to get maximum security. AFAIK 
System76 is doing something similar for their firmware updates. It is a 
small company selling computers with deactivated Intel ME. That is just 
another huge backdoor in any contemporary online computer so the 
computer for compiling would likely need to have a disabled ME.

Re: Have I caught a firmware attack in the act? Or am I just paranoid?






I have only seen intelligence visiting my home when I left an 
offline computer around with HDD.


If you feel safe answering: what country was this in?  Your name and 
time zone suggest Germany/Austria/Switzerland, which I wouldn't have 
thought of as the kind of places that do this.


With the amendment of the StPO 2017, the German Bundestag created a 
legal basis for the widespread use of these so-called Statetrojans[¹]


More states have laws that let they spy citizen with trojans. This 
cause our device/software to be less secure and the same backdoor can 
be used also by others. Also when data is collected is also accessible 
by people who work directly/indirectly and some of these can use that 
data (sell/send to others/read for himself/...)


  Yes, I´d believe it to be a problem when the state buys zero days 
exploits which are then kept secret so that they can continue to be 
exploited. In the worst case people are paid for moving malicious bugs 
in and by selling them later on. The state should act responsible and 
contend to improve the security of our systems instead of undermining 
them. If it is true what I have heard then intelligence services in 
Germany are still using typewriters.

Re: Have I caught a firmware attack in the act? Or am I just paranoid?






I have only seen intelligence visiting my home when I left an offline 
computer around with HDD.


If you feel safe answering: what country was this in?  Your name and 
time zone suggest Germany/Austria/Switzerland, which I wouldn't have 
thought of as the kind of places that do this.


Though I also wouldn't have thought of Britain as the first place to 
have "help us spy and don't tell anyone, or we'll imprison you" legal 
orders until we were...


https://www.eff.org/deeplinks/2016/02/investigatory-powers-bill-and-apple

...which is one reason I prefer to stay away from maintaining security 
tools or other highly sensitive packages.



 Well, I am from Austria and most of what has happened and what you can 
read about took place in Austria:


https://www.elstel.org/CyberAttack-elstel.html.en

... with one exception: The cracked system, where they had replaced 
glibc and some system library files, was cracked in Puno, Peru while I 
had discovered the crack later on in Brazil. Some years ago I have sent 
out blue ray images with the cracked installed system as well as the 
RedHat SELinux packages used to install a clean system 1:1 where you can 
compare both systems, cracked and clean file by file. The sha512-sums of 
these blue ray images are still online at:


https://www.elstel.org/software/

Re: Have I caught a firmware attack in the act? Or am I just paranoid?

2019-08-14 Thread Elmar Stellnberger


Dear Rebecca

Am 13.08.19 um 09:14 schrieb Rebecca N. Palmer:
(b), physical access attack, would require an attacker breaking into 
my home.  (It has been several years since I last took the affected 
flash drive anywhere else or plugged it into any other computer.) If 
they're willing to do that, I seem a strange choice of target: a 
Debian Maintainer is high-value compared to a random user (because 
their uploads can infect others) but probably not the highest-value 
target in a tech-heavy city.


  Just think of central intelligence. They know when you are outside of 
your home by locating your mobile phone and they can easily unlock your 
door because they have access to the lock and key service. Central 
intelligence usually does not target Debian software directly. If a 
malware was distributed via the official release or update service then 
someone would get to know it and proper antivirus/malware detection 
software could be written. They will never do so. They only target 
specific individuals like you - and many people do not know in a first 
hand why they are targeted. What they also do is steeling secret gpg 
keys from computers that are online.


My integrity_check.py script (checking that system files match the 
Debian packages they come from) and clamav don't find such malware, 
but that's not proof.  usbguard probably blocks the DFU method of 
writing to firmware (since I don't have any 0xFE interfaces in my 
allowed list), but at least some USB flash drives instead use an SCSI 
command [1], which usbguard won't catch.


  Have you written something like debcheckroot? If yes I would be 
interested in it. debcheckroot is GPL so it could be an option to 
continue developing it though I did not have the time to do so in the 
last years. However it currently still uses unsafe md5sum. However I 
have not seen the checksum algorithm being targeted directly up to now 
yet. It may be more probable that they simply infect a hidden file in 
your home directory or some binary file like the syslog which then loads 
the malware on every boot. Comparing or checksuming files can not detect 
such kind of malware.


https://www.elstel.org/debcheckroot/

  I would presume that you have booted from DVD when checking your 
installation since it does not make sense to check from within an 
infected system. That would be going to fail in almost 100% of the cases.


I have unplugged the affected flash drive, but either (b) or (c) would 
imply that it may not be the only device infected - and also that even 
if I do replace my whole computer, they may be able to repeat the attack.


  There is hardly any way to get a computer safe except when you remove 
all networking hardware putting the computer offline and then always 
carry the M.2 drive to boot from with you. It would be a question why 
they would target your USB drive and not your computer or why they do 
not simply break in via your email or web browsing program. I have only 
seen intelligence visiting my home when I left an offline computer 
around with HDD.


  In case your are interested here is some more security related 
material on my web page:


https://www.elstel.org/software/GnuPG-usage.html.en

https://www.elstel.org/CyberAttack-elstel.html.en


Regards,

Elmar

Re: Two HDD on Desktop PC

2019-08-05 Thread Elmar Stellnberger


I would not recommend find -delete as it deletes files.

You can easily remove/change a HDD if it is an USB adapter for an M.2 
drive. That is the most secure solution. If you want to be really secure 
you would need to take your computer offline and take the M.2 drive 
always with you.


Booting via USB3.0 does not work on all computers so you may need to 
boot via USB2.0. Precisely at the time when you have loaded the kernel 
you may however remove the drive physically from your USB2.0 plug and 
simply plug it into an USB3.0 slot.


Another solution I had for long with my desktop computer is to carry a 
SATA drive with me and have an external HDD dock. Of course you may also 
use an eSATA case for your HDD if you have an eSATA port.


Some hints on securing your computer can also be found at (see at the 
bottom):


https://www.elstel.org/CyberAttack-elstel.html.en


Am 04.08.19 um 23:57 schrieb Ruslanas Gžibovskis:

1) Unmount deb partition on mint and remove it from /etc/fstab
2) If you just do not want to see it, run: find / -type f -delete
3) before booting into hdd 1 remove hdd2. Before booting hdd2 remove hdd1
4) install Windows or bubuntu on both hdd

Re: PGP/GnuPG unsecure, should be replaced?

2019-07-21 Thread Elmar Stellnberger

Why do you think that TwoFish is bad? It was invented by Bruce Schneier 
and was in the last round of the AES competition. I believe it to be the 
better choice than AES.

Am 20.07.19 um 21:41 schrieb Iain Grant:

2 fish... that in it's self is bad.  AES, sure lets all be ok about that.

I also read the article and I realise I still rely on gpg far too much 
and that I need to ween myself off of it!

Iain

On Sat, Jul 20, 2019 at 8:33 PM qmi (list) > wrote:

Hi,

On 7/19/19 1:34 PM, Stephan Seitz wrote:
> I found the following article about PGP/GnuPG:
> https://latacora.singles/2019/07/16/the-pgp-problem.html
>
> In short you should drop GnuPG because it doesn’t do anything
really
> the right way. It should be replaced with different tools for
> different situations.

I checked that article. For e.g. the article says, "If you’re lucky,
your local GnuPG defaults to 2048-bit RSA, the 64-bit-block CAST5
cipher
in CFB, ..."

Wrong. The current implementation of GnuPG shipped by Debian Buster -
version 2.2.12 - does support modern cryptographic standards for
symmetric encryption, not only CAST5. For e.g., it does support
twofish
and aes. Both of which use 128-bit block sizes, AFAIK. See command
output for gpg below about supported algorithms:

"

qmi@qmiacer:~$ gpg --version

gpg (GnuPG) 2.2.12
(...)
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
 CAMELLIA128, CAMELLIA192, CAMELLIA256
(...)
"

So it's good enough, apparently.

>
> Debian is using GnuPG for signing files. From the article:
>
> Signing Packages
>
> Use Signify/Minisign. Ted Unangst will tell you all about it.
It’s what

You may be right, though. That tool might have better bindings for
modern programming languages.

Regards,
--
qmi
Email: li...@miklos.info

Re: Intel Microcode updates

2019-06-23 Thread Elmar Stellnberger

If it is already described in the readme (I did not get this from the 
comments) then I´d consider that a good solution.


I did not know. I will have to do that on my own in a short while 
because I still have many Core 2 systems.


As I read from the latest comments the microcode updates for Core 2 
systems are officially shipped by Intel via the internet though Intel 
denies this in another place apparently for marketing purposes. If this 
is really true I guess the update should be shipped by the usual means 
as for later CPUs.



Am 23.06.19 um 22:28 schrieb Henrique de Moraes Holschuh:

On Tue, 18 Jun 2019, Elmar Stellnberger wrote:

Perhaps you could add a bash script that does automatically download the
microcode like f.i. winetricks does with windows code. That way one could be
more sure to use the right url for it. I also still have quite a lot of Core
2 computers and would thus profit from such a provision.

I can add it as an example, sure, if someone writes one that is good
enough to share and sends it as a *whishlist* bug to the BTS with the
patch.

But I fear it will be pointless.  The README already tells you how to do
it yourself, and people won't read it, why would them find about an
example downloader script?

I have been quite clear enough in my reply below about microcode updates
sourced from random places, so such a downloader would *HAVE* to
download from the official microcode updates distribution, anyway.


Am 12.06.19 um 16:52 schrieb Henrique de Moraes Holschuh:

(BCC'd to #929073 to avoid dragging the BTS into this thread).

On Tue, 11 Jun 2019, Moritz Mühlenhoff wrote:

Russell Coker  schrieb:

Should it be regarded as a bug in the intel-microcode package that it doesn't
have this update that is "easy enough to source"?  Or do you mean "easy to get
but not licensed for distribution"?

This is covered by #929073, which links to a PDF by Intel (which documents
that Intel won't ship an update for your CPU).

I'd like to add that:

We do not, and will not, distribute in non-free's intel-microcode
anything we did not get from Intel (or from someone else who got it from
Intel with permission to redistribute).  This ensures all microcode
updates we distribute in non-free are under a license that allows
redistribution.

Note that, as long as there are very good reasons to do so, I am willing
to distribute microcode updates that are no longer being distributed[1],
since we did receive it with an appropriate license that allows
redistribution in the first place.

Also, one can place whatever microcode updates they got from wherever to
/usr/share/misc/intel-microcode*.bin at their own risk and
responsibility, and the intel-microcode package will attempt to use it.

[1] as in: "they were being distributed by Intel on the Linux microcode
update package in the past, and for more than one release of Intel's
microcode update package".

Re: Intel Microcode updates

2019-06-22 Thread Elmar Stellnberger

Perhaps you could add a bash script that does automatically download the 
microcode like f.i. winetricks does with windows code. That way one 
could be more sure to use the right url for it. I also still have quite 
a lot of Core 2 computers and would thus profit from such a provision.


Am 12.06.19 um 16:52 schrieb Henrique de Moraes Holschuh:

(BCC'd to #929073 to avoid dragging the BTS into this thread).

On Tue, 11 Jun 2019, Moritz Mühlenhoff wrote:

Russell Coker  schrieb:
Should it be regarded as a bug in the intel-microcode package that 
it doesn't
have this update that is "easy enough to source"? Or do you mean 
"easy to get

but not licensed for distribution"?
This is covered by #929073, which links to a PDF by Intel (which 
documents

that Intel won't ship an update for your CPU).

I'd like to add that:

We do not, and will not, distribute in non-free's intel-microcode
anything we did not get from Intel (or from someone else who got it from
Intel with permission to redistribute). This ensures all microcode
updates we distribute in non-free are under a license that allows
redistribution.

Note that, as long as there are very good reasons to do so, I am willing
to distribute microcode updates that are no longer being distributed[1],
since we did receive it with an appropriate license that allows
redistribution in the first place.

Also, one can place whatever microcode updates they got from wherever to
/usr/share/misc/intel-microcode*.bin at their own risk and
responsibility, and the intel-microcode package will attempt to use it.

[1] as in: "they were being distributed by Intel on the Linux microcode
update package in the past, and for more than one release of Intel's
microcode update package".

Re: Intel Microcode updates

2019-06-22 Thread Elmar Stellnberger

  Just because you disable Javascript in your browser I would not trust 
that you will be save from arbitrary code execution. I am using 
Thunderbird as an email client and it has the same intrusion problem as 
the browsers running Javascript. The arbitrary binary code execution 
problem does to my believe more relate to common vulnerabilities like 
buffer overflows in the whole code than just to the Javascript subsystem 
which is of course an additional security risk. As long as the code base 
is changing rapidly and as long as new arbitrary code execution problems 
are discovered from time to time you are not save. The speed new bugs 
are moved in is simply higher than the speed by with some of the old 
bugs are corrected for browsers like Chromium or Firefox (I would not 
trust software from Google anyway as it is part of the empire of 
'evil'.). Intelligence services usually use zero days exploits for which 
there is no known mitigation. If you wanna be save on a computer do not 
use an email client or web browser; at least not if it can connect to 
sites spoofed by secret services. To avoid connecting to a 1:1 mirror 
site of an intelligence service we would need an improvement of https 
certificate management like f.i. DANE provides. There are many rogue 
certificates issued for intelligence services out there and restricting 
your browser to use https does not help.


Regards,
Elmar



Am 11.06.19 um 21:09 schrieb Andrew McGlashan:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,


On 12/6/19 3:16 am, Holger Levsen wrote:

On Wed, Jun 12, 2019 at 03:05:13AM +1000, Andrew McGlashan
wrote:

Exploiting the flaws needs malicious code to be running on your
box. If you are in total control over all VMs and processes
on the box, then you should be good.

do you use a webbrowser with javascript enabled?

Good point, yes that is another risk.

Actually though, if you update your browser to lessen the granularity
of time that the exploits require, it might not be an issue. So,
don't run an out of date browser is that enough?

Cheers
A.
-BEGIN PGP SIGNATURE-

iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCXP/8eAAKCRCoFmvLt+/i
+2AsAP4knXw4eLsVrlYm/CwuWJrhGC8FRVj4Uc09H0mR2ZDlhwD/RI/FDdLYiO9t
nNNga1FHGhCMj7v/rzJcZ/8iGrNrmqI=
=/5dj
-END PGP SIGNATURE-

Re: Intel Microcode updates

Perhaps you could add a bash script that does automatically download the 
microcode like f.i. winetricks does with windows code. That way one 
could be more sure to use the right url for it. I also still have quite 
a lot of Core 2 computers and would thus profit from such a provision.


Am 12.06.19 um 16:52 schrieb Henrique de Moraes Holschuh:

(BCC'd to #929073 to avoid dragging the BTS into this thread).

On Tue, 11 Jun 2019, Moritz Mühlenhoff wrote:

Russell Coker  schrieb:
Should it be regarded as a bug in the intel-microcode package that 
it doesn't
have this update that is "easy enough to source"? Or do you mean 
"easy to get

but not licensed for distribution"?
This is covered by #929073, which links to a PDF by Intel (which 
documents

that Intel won't ship an update for your CPU).

I'd like to add that:

We do not, and will not, distribute in non-free's intel-microcode
anything we did not get from Intel (or from someone else who got it from
Intel with permission to redistribute). This ensures all microcode
updates we distribute in non-free are under a license that allows
redistribution.

Note that, as long as there are very good reasons to do so, I am willing
to distribute microcode updates that are no longer being distributed[1],
since we did receive it with an appropriate license that allows
redistribution in the first place.

Also, one can place whatever microcode updates they got from wherever to
/usr/share/misc/intel-microcode*.bin at their own risk and
responsibility, and the intel-microcode package will attempt to use it.

[1] as in: "they were being distributed by Intel on the Linux microcode
update package in the past, and for more than one release of Intel's
microcode update package".

Re: Intel Microcode updates

  Just because you disable Javascript in your browser I would not trust 
that you will be save from arbitrary code execution. I am using 
Thunderbird as an email client and it has the same intrusion problem as 
the browsers running Javascript. The arbitrary binary code execution 
problem does to my believe more relate to common vulnerabilities like 
buffer overflows in the whole code than just to the Javascript subsystem 
which is of course an additional security risk. As long as the code base 
is changing rapidly and as long as new arbitrary code execution problems 
are discovered from time to time you are not save. The speed new bugs 
are moved in is simply higher than the speed by with some of the old 
bugs are corrected for browsers like Chromium or Firefox (I would not 
trust software from Google anyway as it is part of the empire of 
'evil'.). Intelligence services usually use zero days exploits for which 
there is no known mitigation. If you wanna be save on a computer do not 
use an email client or web browser; at least not if it can connect to 
sites spoofed by secret services. To avoid connecting to a 1:1 mirror 
site of an intelligence service we would need an improvement of https 
certificate management like f.i. DANE provides. There are many rogue 
certificates issued for intelligence services out there and restricting 
your browser to use https does not help.


Regards,
Elmar



Am 11.06.19 um 21:09 schrieb Andrew McGlashan:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,


On 12/6/19 3:16 am, Holger Levsen wrote:

On Wed, Jun 12, 2019 at 03:05:13AM +1000, Andrew McGlashan
wrote:

Exploiting the flaws needs malicious code to be running on your
box. If you are in total control over all VMs and processes
on the box, then you should be good.

do you use a webbrowser with javascript enabled?

Good point, yes that is another risk.

Actually though, if you update your browser to lessen the granularity
of time that the exploits require, it might not be an issue. So,
don't run an out of date browser is that enough?

Cheers
A.
-BEGIN PGP SIGNATURE-

iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCXP/8eAAKCRCoFmvLt+/i
+2AsAP4knXw4eLsVrlYm/CwuWJrhGC8FRVj4Uc09H0mR2ZDlhwD/RI/FDdLYiO9t
nNNga1FHGhCMj7v/rzJcZ/8iGrNrmqI=
=/5dj
-END PGP SIGNATURE-

Re: Intel Microcode updates

Perhaps you could add a bash script that does automatically download the 
microcode like f.i. winetricks does with windows code. That way one 
could be more sure to use the right url for it. I also still have quite 
a lot of Core 2 computers and would thus profit from such a provision.


Am 12.06.19 um 16:52 schrieb Henrique de Moraes Holschuh:

(BCC'd to #929073 to avoid dragging the BTS into this thread).

On Tue, 11 Jun 2019, Moritz Mühlenhoff wrote:

Russell Coker  schrieb:

Should it be regarded as a bug in the intel-microcode package that it doesn't
have this update that is "easy enough to source"?  Or do you mean "easy to get
but not licensed for distribution"?

This is covered by #929073, which links to a PDF by Intel (which documents
that Intel won't ship an update for your CPU).

I'd like to add that:

We do not, and will not, distribute in non-free's intel-microcode
anything we did not get from Intel (or from someone else who got it from
Intel with permission to redistribute).  This ensures all microcode
updates we distribute in non-free are under a license that allows
redistribution.

Note that, as long as there are very good reasons to do so, I am willing
to distribute microcode updates that are no longer being distributed[1],
since we did receive it with an appropriate license that allows
redistribution in the first place.

Also, one can place whatever microcode updates they got from wherever to
/usr/share/misc/intel-microcode*.bin at their own risk and
responsibility, and the intel-microcode package will attempt to use it.

[1] as in: "they were being distributed by Intel on the Linux microcode
update package in the past, and for more than one release of Intel's
microcode update package".

Re: Intel Microcode updates