Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.security > #5646 > unrolled thread

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

Back to article view | Back to linux.debian.security

Contents

  Have I caught a firmware attack in the act? Or am I just paranoid? "Rebecca N. Palmer" <rebecca_palmer@zoho.com> - 2019-08-13 09:40 +0200
    Re: Have I caught a firmware attack in the act? Or am I just paranoid? Paul Wise <pabs@debian.org> - 2019-08-14 07:10 +0200
    Re: Have I caught a firmware attack in the act? Or am I just  paranoid? Elmar Stellnberger <estellnb@gmail.com> - 2019-08-14 17:40 +0200
      Re: Have I caught a firmware attack in the act? Or am I just  paranoid? "Rebecca N. Palmer" <rebecca_palmer@zoho.com> - 2019-08-15 23:20 +0200
        Re: Have I caught a firmware attack in the act? Or am I just  paranoid? Davide Prina <davide.prina@gmail.com> - 2019-08-16 10:40 +0200
          Re: Have I caught a firmware attack in the act? Or am I just  paranoid? CMH <chouck@binghamton.edu> - 2019-08-16 14:20 +0200
          Re: Have I caught a firmware attack in the act? Or am I just paranoid? Andrei Grosu <andrei_grosu@fastmail.net> - 2019-08-16 19:20 +0200
          Re: Have I caught a firmware attack in the act? Or am I just  paranoid? Elmar Stellnberger <estellnb@gmail.com> - 2019-08-16 19:20 +0200
        Re: Have I caught a firmware attack in the act? Or am I just  paranoid? Elmar Stellnberger <estellnb@gmail.com> - 2019-08-16 19:10 +0200
        Re: Have I caught a firmware attack in the act? Or am I just  paranoid? Elmar Stellnberger <estellnb@gmail.com> - 2019-08-16 19:30 +0200
        Re: Have I caught a firmware attack in the act? Or am I just  paranoid? Elmar Stellnberger <estellnb@gmail.com> - 2019-08-16 21:20 +0200
          Re: Have I caught a firmware attack in the act? Or am I just  paranoid? "Rebecca N. Palmer" <rebecca_palmer@zoho.com> - 2019-08-17 11:50 +0200
            Re: Have I caught a firmware attack in the act? Or am I just  paranoid? Elmar Stellnberger <estellnb@gmail.com> - 2019-08-17 13:20 +0200
              Re: Have I caught a firmware attack in the act? Or am I just  paranoid? "Rebecca N. Palmer" <rebecca_palmer@zoho.com> - 2019-08-23 09:30 +0200
                Re: Have I caught a firmware attack in the act? Or am I just  paranoid? Elmar Stellnberger <estellnb@gmail.com> - 2019-08-23 21:00 +0200
                  debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2019-11-15 17:20 +0100
                    Verified Boot, Secure Boot, dm-verity, debcheckroot Patrick Schleizer <adrelanos@riseup.net> - 2019-11-16 14:00 +0100
                      Re: Verified Boot, Secure Boot, dm-verity, debcheckroot Elmar Stellnberger <estellnb@gmail.com> - 2019-11-16 15:30 +0100
                        Re: Verified Boot, Secure Boot, dm-verity, debcheckroot Sylvain Beucler <beuc@beuc.net> - 2019-11-16 15:40 +0100
                      Re: Verified Boot, Secure Boot, dm-verity, debcheckroot Elmar Stellnberger <estellnb@gmail.com> - 2019-11-16 15:40 +0100
                    Re: debcheckroot v2.0 released Patrick Schleizer <adrelanos@riseup.net> - 2019-11-19 13:40 +0100
                      Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2019-11-20 12:30 +0100
                        Re: debcheckroot v2.0 released Patrick Schleizer <adrelanos@riseup.net> - 2019-11-25 12:40 +0100
                          Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2019-11-25 18:00 +0100
                            Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2019-12-10 17:40 +0100
                          Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2019-11-27 12:10 +0100
                            Re: debcheckroot v2.0 released Cindy Sue Causey <butterflybytes@gmail.com> - 2020-01-17 14:40 +0100
                              Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2020-01-17 17:00 +0100
                                Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2020-01-17 17:20 +0100
                                Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2020-03-04 20:20 +0100
                                  Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2020-03-04 20:50 +0100
                                    Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2020-03-04 21:00 +0100
                                      Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2020-03-04 21:00 +0100
                                        Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2020-03-23 17:10 +0100
                                          Re: debcheckroot v2.0 released Paul Wise <pabs@debian.org> - 2020-03-24 04:40 +0100
                                            Re: debcheckroot v2.0 released Paul Wise <pabs@debian.org> - 2020-03-24 11:20 +0100
                                              Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-03-24 15:50 +0100
                                                Re: debcheckroot v2.0 released Paul Wise <pabs@debian.org> - 2020-03-25 03:00 +0100
                                                  Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-03-25 11:30 +0100
                                                    Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-03-26 11:10 +0100
                                                      Re: debcheckroot v2.0 released "vince@vheuser.com" <vince@vheuser.com> - 2020-04-01 20:10 +0200
                                                        Re: debcheckroot v2.0 released Paul Wise <pabs@debian.org> - 2020-04-02 02:00 +0200
                                                          Re: debcheckroot v2.0 released Lewis Yarema <lewisyarema91@gmail.com> - 2020-04-02 11:20 +0200
                                                            Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-04-02 17:00 +0200
                                                              Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-04-03 13:40 +0200
                                                          Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-04-02 16:50 +0200
                                                            Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-04-04 09:50 +0200
                                                              Re: debcheckroot v2.0 released William Gagnebé <william.gagnebe@gmail.com> - 2020-04-05 12:20 +0200
                                                                Re: debcheckroot v2.0 released l0f4r0@tuta.io - 2020-04-05 12:30 +0200
                                                              Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-04-07 17:50 +0200
                                                          Re: debcheckroot v2.0 released "Niall O'Reilly" <Niall.oReilly+lists@no8.be> - 2020-04-02 18:30 +0200
                                                          Re: debcheckroot v2.0 released Lee <ler762@gmail.com> - 2020-04-02 21:00 +0200
                                                            Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-04-02 21:40 +0200
                                                              Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-04-03 13:50 +0200
                                                                Re: debcheckroot v2.0 released Lee <ler762@gmail.com> - 2020-04-04 00:50 +0200
                                                                  Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-04-04 09:40 +0200
                                                          Re: debcheckroot v2.0 released Bjørn Mork <bjorn@mork.no> - 2020-04-14 09:30 +0200
                                                            arbitrary code execution on unformatted usb stick Elmar Stellnberger <estellnb@elstel.org> - 2020-04-25 15:40 +0200
                                                              Re: arbitrary code execution on unformatted usb stick Elmar Stellnberger <estellnb@elstel.org> - 2020-04-25 15:50 +0200
                                                              Re: arbitrary code execution on unformatted usb stick Elmar Stellnberger <estellnb@elstel.org> - 2020-05-02 17:00 +0200
                                                                Re: arbitrary code execution on unformatted usb stick Elmar Stellnberger <estellnb@elstel.org> - 2020-05-02 17:10 +0200
                                                                  Fwd: Re: arbitrary code execution on unformatted usb stick estellnb@elstel.org - 2020-05-02 20:50 +0200
                                    Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2020-03-21 17:40 +0100
        Probably a false alarm Re: Have I caught a firmware attack in the  act? Or am I just paranoid? "Rebecca N. Palmer" <rebecca_palmer@zoho.com> - 2019-08-24 18:50 +0200

Page 1 of 4  [1] 2 3 4  Next page →

#5646 — Have I caught a firmware attack in the act? Or am I just paranoid?

(Warning: this is being sent from the affected computer, so don't trust 
"me".  BCCd recipients: anyone can post to the debian-security list, but 
be aware that its public archive does not spam-protect email addresses)

I use usbguard [0], set to allow only the specific USB devices I have.

One of my flash drives apparently stopped working, and investigation 
found that it had changed Product ID, causing usbguard to block it as an 
unrecognized device.

Possible explanations - all seem unlikely but it has to be something:
(a) Innocent device malfunction
(b) Malware infection [1-2] via physical access to the drive
(c) Malware infection that began in the computer then infected the drive

(a), innocent malfunction, has the problem that the new Product ID 
number is not just a bit flip away and the strings changed as well. 
(Unless the firmware has two descriptors and a switch bit? or a built-in 
default + a rewritable configuration, and the flash block containing the 
latter has died?)

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

(c), malware on my computer, requires getting around the fact that I 
haven't recently installed anything from outside Debian except my own 
package.  Maybe a Firefox/Thunderbird sandbox escape?

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.

Both the old and new Product IDs are listed in 
/lib/udev/hwdb.d/20-usb-vendor-model.hwdb as flash drives, and it 
continued to have only a mass storage (class 08: subclass 06: protocol 
0x50) interface, i.e. if it is malware it's not using the obvious 
"pretend to be a keyboard" route.

I'm also not sure whether firmware-based malware is common enough to be 
something the average developer should worry about.  I have seen many 
reports of the possibility, but the news tends to emphasize rare events, 
and the reports I've seen of actual in-the-wild examples are ones that 
target Windows not Linux.

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.

[0] https://usbguard.github.io/
[1] (non-trust warning: found via Wikipedia) 
https://srlabs.de/wp-content/uploads/2014/07/SRLabs-BadUSB-BlackHat-v1.pdf
[2] https://opensource.srlabs.de/projects/badusb/wiki/USB_storage

syslog - before:

Aug  5 07:21:51 rnpalmer-laptop kernel: [34901.758073] usb 3-2.1: New 
USB device found, idVendor=058f, idProduct=6387
Aug  5 07:21:51 rnpalmer-laptop kernel: [34901.758077] usb 3-2.1: New 
USB device strings: Mfr=1, Product=2, SerialNumber=3
Aug  5 07:21:51 rnpalmer-laptop kernel: [34901.758080] usb 3-2.1: 
Product: Mass Storage
Aug  5 07:21:51 rnpalmer-laptop kernel: [34901.758082] usb 3-2.1: 
Manufacturer: Generic
Aug  5 07:21:51 rnpalmer-laptop kernel: [34901.758084] usb 3-2.1: 
SerialNumber: F32402A6
Aug  5 07:21:51 rnpalmer-laptop kernel: [34901.758274] usb 3-2.1: Device 
is not authorized for usage
[...]
Aug  5 07:21:51 rnpalmer-laptop kernel: [34901.953787] usb 3-2.1: 
authorized to connect

syslog - after:

[these are messages that are saved after hibernation, but the first ones 
may actually have been generated before it; it is not normal to get "new 
USB device" at this time]
Aug  6 21:52:26 rnpalmer-laptop kernel: [50368.297466] usb 3-2.1: reset 
high-speed USB device number 21 using xhci_hcd
Aug  6 21:52:26 rnpalmer-laptop kernel: [50368.605593] usb 3-2.1: device 
firmware changed [ from the source code this actually means "descriptor 
changed", 
https://sources.debian.org/src/linux/4.9.168-1/drivers/usb/core/hub.c/#L5520 
]
[...]
Aug  6 21:52:26 rnpalmer-laptop kernel: [50370.579113] usb 3-2.1: New 
USB device found, idVendor=058f, idProduct=1234
Aug  6 21:52:26 rnpalmer-laptop kernel: [50370.579117] usb 3-2.1: New 
USB device strings: Mfr=1, Product=2, SerialNumber=0
Aug  6 21:52:26 rnpalmer-laptop kernel: [50370.579119] usb 3-2.1: 
Product: Mass Storage Device
Aug  6 21:52:26 rnpalmer-laptop kernel: [50370.579121] usb 3-2.1: 
Manufacturer: Alcor Micro
Aug  6 21:52:26 rnpalmer-laptop kernel: [50370.579255] usb 3-2.1: Device 
is not authorized for usage

[toc] | [next] | [standalone]

#5647

On Tue, Aug 13, 2019 at 3:30 PM Rebecca N. Palmer wrote:

> but at least some USB flash drives instead use an SCSI command [1],
> which usbguard won't catch.

This seems like a significant missing feature, but I guess it would
require a fair bit of Linux kernel work to support filtering such
commands.

> I'm also not sure whether firmware-based malware is common enough to be
> something the average developer should worry about.

IMO proprietary software is worrisome in any context and the Linux
kernel definitely needs hardening against malicious devices. There has
been some recent work on exploiting radio firmware and then exploiting
Linux from there, here are two examples that come to mind:

https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html
https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_11.html
https://blade.tencent.com/en/advisories/qualpwn/

> Aug  5 07:21:51 rnpalmer-laptop kernel: [34901.758084] usb 3-2.1:
> SerialNumber: F32402A6

This got deleted.

> Aug  6 21:52:26 rnpalmer-laptop kernel: [50370.579113] usb 3-2.1: New
> USB device found, idVendor=058f, idProduct=1234

This vendor/product combo is known to usb.ids:

/usr/share/misc/usb.ids:058f  Alcor Micro Corp.
/usr/share/misc/usb.ids:    1234  Flash Drive
...
/usr/share/misc/usb.ids:    6387  Flash Drive
...
/usr/share/misc/usb.ids:    9380  Flash Drive
/usr/share/misc/usb.ids:    9381  Flash Drive
/usr/share/misc/usb.ids:    9382  Acer/Sweex Flash drive

> Aug  6 21:52:26 rnpalmer-laptop kernel: [50370.579117] usb 3-2.1: New
> USB device strings: Mfr=1, Product=2, SerialNumber=0

The serial number went to zero.

> Aug  6 21:52:26 rnpalmer-laptop kernel: [50370.579121] usb 3-2.1:
> Manufacturer: Alcor Micro

This changed from "Generic" and idVendor=058f is Alcor Micro.

Based on the serial number deletion, I'd speculate that some internal
part of the flash holding details about the device identity
malfunctioned, so the firmware reverted back to the default hardcoded
product id for Alcor flash drives. No idea if this is a reasonable
theory or what caused the malfunction, malware or otherwise.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

Paul Wise wrote:
>> but at least some USB flash drives instead use an SCSI command [1],
>> which usbguard won't catch.
> 
> This seems like a significant missing feature, but I guess it would
> require a fair bit of Linux kernel work to support filtering such
> commands.

If the attacker has root (which they need to use either firmware update 
mechanism anyway) on the base system, they've already won: they can 
simply uninstall usbguard or similar tools.

If the attacker is in a VM/container, writing to firmware is a possible 
escape route, but I'm not sure whether usbguard or the VM software is a 
better place to address it.

I think of usbguard as mostly for blocking the device-to-host (not 
host-to-device) direction of infection, specifically devices that 
pretend to be keyboards and "type" malicious commands.

> Based on the serial number deletion, I'd speculate that some internal
> part of the flash holding details about the device identity
> malfunctioned, so the firmware reverted back to the default hardcoded
> product id for Alcor flash drives. No idea if this is a reasonable
> theory or what caused the malfunction, malware or otherwise.

It makes sense for the firmware to have a fixed bootloader part: USB is 
a complex enough protocol that accepting firmware updates over it is 
likely to itself require firmware, and the (different) brand that has 
publicly been attacked does have one:

https://srlabs.de/wp-content/uploads/2014/11/SRLabs-BadUSB-Pacsec-v2.pdf

On 14/08/2019 16:31, Elmar Stellnberger wrote:

> 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

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

>    Have you written something like debcheckroot? If yes I would be 
> interested in it.

https://lists.debian.org/debian-security/2018/02/msg00012.html

The check script is config/includes.chroot/usr/local/bin/integrity_check.py

> 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 

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.

>    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 

My GPG keys are offline in that I only insert them after booting from a 
DVD with a no-networking kernel, but as this is on the same physical 
computer (which doesn't have a hardware-level way to disable 
networking), a firmware attack could bypass this.

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

[toc] | [prev] | [next] | [standalone]

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

On 15/08/19 22:57, Rebecca N. Palmer wrote:

>> 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/...)

Ciao
Davide

[¹]
https://www.spiegel.de/international/germany/state-spyware-german-court-permits-restricted-online-surveillance-a-538094.html


-- 
Dizionari: http://linguistico.sourceforge.net/wiki
Esci dall'illegalità: utilizza LibreOffice/OpenOffice:
http://linguistico.sf.net/wiki/doku.php?id=usaooo
Non autorizzo la memorizzazione del mio indirizzo su outlook

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

*Benjamin Franklin* once said: "Those who would *give up* essential 
Liberty, to purchase a little temporary Safety, deserve neither Liberty 
nor Safety."
I suspect statesman of many nations have made similar declarators.

Why is privacy almost complete gone (IMHO) ...
1. The strange need to post the most  intimate  details of ones life on 
Social Media.
2. No one is afraid of anything, but there is a complete lack of bravery.
3. The detestable need for 'me' to know any and all information about 
'you', and the self-rationalization that it is OK..

>>> 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/...)
>
> Ciao
> Davide
>
> [¹]
> https://www.spiegel.de/international/germany/state-spyware-german-court-permits-restricted-online-surveillance-a-538094.html 
>
>
>

-- 
Systems Since 1948
Craig M. Houck ><>
Tech Hub/Computer Center
    3rd Floor 332
      607 777 6827
We are only as good as the problems we solve!

[toc] | [prev] | [next] | [standalone]

#5653

unsubscribe 😭

> On 16 Aug 2019, at 19:16, Elmar Stellnberger <estellnb@gmail.com> wrote:
> 
> 
>> 
>>>> 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.
> 

[toc] | [prev] | [next] | [standalone]

#5654 — 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.

[toc] | [prev] | [next] | [standalone]

#5652 — 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/

[toc] | [prev] | [next] | [standalone]

#5655 — 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.

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

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

I have now done the check from a boot DVD: clean, but as already noted, 
there are places it doesn't check.

On 16/08/2019 20:14, Elmar Stellnberger wrote:
> 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.

Only as a better-than-nothing method if the .deb isn't cached - if it is 
(which it is on my system), it checks the whole hash tree (which uses 
sha256) up to the Release signature (using the debian-archive-keyring 
from the checker DVD if you're using one).

Manual hash lists are also supported.

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

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

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

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/

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

#5705 — debcheckroot v2.0 released

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#5707 — Verified Boot, Secure Boot, dm-verity, debcheckroot

I am very interested in Verified Boot. Was wondering how it could be
implemented on a Linux desktop distribution such as Debian. I would like
to implement in Debian derivatives, that I maintain (Whonix, Kicksecure).

Came up with some ideas which I will share here.

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

= User Freedom =

Freedom Software can be compatible with Verified Boot. No user freedom
restrictions required. While verified boot is often used to restrict
user freedom, to prevent the user from modifications and installing
another operating system, Verified Boot is not inherently bad.
User-controlled keys are possible.

https://blog.torproject.org/mission-improbable-hardening-android-security-and-privacy
Quote

> Nexus and Pixel lines support Verified Boot with user-controlled keys

= Concepts =
== Verified VM Boot Sequence without Secure Boot ==

(Same security level as Secure Boot?)

Talking about VMs only in this concept.

We could boot from a virtual, read-only (write protected) boot medium
such as another virtual HDD or ISO. Such a boot medium which only
contains a bootloader (shim or grub?) which only task is to verify the
bootloader on the main hard drive that contains the bootloader, kernel,
debian. That boot medium (such as IOS) could be shipped on Whonix Host
through a `deb` package `/usr/share/verified-boot/check.iso`.

Presuppositions:

* the virtual BIOS cannot be flashed/compromised
* host not compromised

boot sequence:

VM powered on -> virtual BIOS loads boot DVD ISO (or alternatively
another hard drive) (contains a bootloader only) -> this initial
bootloader signature is not verified but secure since boot from
read-only medium -> verify bootloader on main hard drive -> bootloader
of main hard drive does signature verification of kernel -> continue boot

What we need for that: `grub-pc` (not `grub-efi`) with signature
verification.

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939188
* https://savannah.gnu.org/bugs/index.php?56887

By not booting from that initial boot medium (for testing or if that was
broken or so), users could do regular boots without verification of the
bootloader on the main drive. From the perspective of the main drive,
nothing would change. Except we'd enable grub signature verification of
the kernel on the main drive.

The boot medium should not load the actual kernel for simplicity of the
implementation. Since it is read-only it cannot be easily updated.
Kernel packages change and during kernel upgrades `/boot` and `grub.cfg`
on the main disk changes. If `/boot` was write protected, that would
fail. Therefore the initial boot medium is only a simplified alternative
to EFI Secure Boot. By making the initial boot medium as simple as
possible, i.e. only chainloading the next bootloader, it does not need
frequent updates and does not need to be updated when kernel versions
change.

If we could make `grub-pc` (not `grub-efi`) use
`check_signatures=enforce`, then maybe we don't need to port to EFI
and/or Secure Boot soon and perhaps never?

The disadvantage of this concept is that it is only as secure as Secure
Boot.

initrd could still be compromised:
https://forums.whonix.org/t/enable-linux-kernel-gpg-verification-in-grub-and-or-enable-secure-boot-by-default/7894/30?u=patrick

== Hash Check all Files at Boot ==
Higher security level as Secure Boot.

Talking about VMs only in this concept.

We could boot from a virtual, read-only (write protected) boot medium
such as another virtual HDD or ISO. Such a boot medium which runs a
minimal linux distribution which then compares against checksums from
Debian repository on the main boot drive:

* The MBR (master boot record)
* The VBR (volume boot record)
* [A] the booloader
* [B] the partition table
* [C] the kernel
* [D] the initrd
* [E] all files shipped by all packages

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/

> Usage of debsums instead of Debian-checkroot is strongly discouraged
because debsums uses locally stored md5sums which can be modified by an
attacker along with the files themselves. It has been meant for
integrity checking not for security issues! Debsums furthermore does not
provide an output as clean and neatly structured as checkroot and does
not spot files additionally added to your system by someone else.


A tool such as debcheckroot might be more suitable for this task.

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

https://github.com/Whonix/Whonix/blob/master/build-steps.d/2800_create-report

Extraneous files would be reported, with option to delete them, to move
them to quarantaine and/or to view them.

Initrd is by Debian default, auto generated on the local system. Hence,
there is nothing to compare with from Debian repository. However, after
verification of everything (all files from all packages) it would be
secure to chroot into the verified system and to re-generate the initrd.
Then to compare both versions. This might not be required if initrd can
be extracted and compared against files on the root disk.

That boot medium (such as IOS) could be shipped on Whonix Host through a
`deb` package `/usr/share/verified-boot/check.iso`.

Disadvantage of this concept might be that it might be slower than
dm-verity. On the other hand the advantage of this concept is that this
does not require a OEM image. Also it might be more secure since it does
not verify against an OEM image but would verify the individual files.
Another advantage is that users are free to install any package and not
limited by a readonly root image. Users do not have to wait for the
vendor to update the OEM image.

= Status =
Help welcome to implement this.

= Other Distributions implementing Verified Boot =
* https://docs.clip-os.org/clipos/boot_integrity.html
* https://source.android.com/security/verifiedboot/
* https://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot

= Forum Discussion =
https://forums.whonix.org/t/enable-linux-kernel-gpg-verification-in-grub-and-or-enable-secure-boot-by-default/7894

Cheers,
Patrick

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
> 

[toc] | [prev] | [next] | [standalone]

#5708 — Re: Verified Boot, Secure Boot, dm-verity, debcheckroot

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

[toc] | [prev] | [next] | [standalone]

#5709 — Re: Verified Boot, Secure Boot, dm-verity, debcheckroot

Hi,

On 16/11/2019 15:22, Elmar Stellnberger wrote:
>
>> 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).

The output can vary depending on build path, build date, files ordering,
and of course build dependencies.
For the compiler it is recommended to set SOURCE_DATE_EPOCH to trigger
deterministic behavior.

https://reproducible-builds.org/docs/ has a lot more on this :)

Cheers!
Sylvain

[toc] | [prev] | [next] | [standalone]

#5710 — Re: Verified Boot, Secure Boot, dm-verity, debcheckroot

> 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

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | linux.debian.security

csiph-web