Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.security > #5646 > unrolled thread
| Started by | "Rebecca N. Palmer" <rebecca_palmer@zoho.com> |
|---|---|
| First post | 2019-08-13 09:40 +0200 |
| Last post | 2019-08-24 18:50 +0200 |
| Articles | 4 on this page of 64 — 18 participants |
Back to article view | Back to linux.debian.security
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 4 of 4 — ← Prev page 1 2 3 [4]
| From | Elmar Stellnberger <estellnb@elstel.org> |
|---|---|
| Date | 2020-05-02 17:10 +0200 |
| Subject | Re: arbitrary code execution on unformatted usb stick |
| Message-ID | <A21Wa-2Ng-13@gated-at.bofh.it> |
| In reply to | #5818 |
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 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 > remember my German email from last time?). There is for sure a bug in > the vfat driver. My System76 notebook was clean as otherwise they would > never have left me develop a̅tea on it up to the state in which the tool > is at the present time. However there are some things that would need to > be done for a̅tea. That DoH/DoT shit in libunbound has an arbitrary code > execution bug which concerns a̅tea every time you do not state the server > certificate on the command line. You can download the server certificate > securely with dig or drill so the tool is basically already fully > functional. I would replace libunbound with direct system calls for DNS > and verify the trust chain up to the final RRSIG manually by the > program. If that condition was met, a̅tea would be fully secure and > functional. We have also been talking about missing DANE support for web > browsers. I know an easy-to-implement workaround: A https proxy with a > Firefox-local configured certification authority. It would forward > DANE-enabled sites 1:1 with self-generated certificates. Something that > would work for all browsers you can think of. Unfortunately I have no > way to implement that as the ultimate defenders of our freedom would > simply turn my computer off if I attempted to program anything the like. > This is bitter truth! > > > > >
[toc] | [prev] | [next] | [standalone]
| From | estellnb@elstel.org |
|---|---|
| Date | 2020-05-02 20:50 +0200 |
| Subject | Fwd: Re: arbitrary code execution on unformatted usb stick |
| Message-ID | <A25n6-4Hc-7@gated-at.bofh.it> |
| In reply to | #5819 |
I am forwarding you this email in the hope that it will be useful: (They simply could not have known what reason I was installing mininet for and that I would try to install it at all if they would not have observed what I was doing even if they would have supposed that I wanna continue on a̅tea. Besides this kind of live-blocking every step that would be useful to achieve my goal is noteable on a computer that I believed to be totally clean in the time before. That was how things started to uncover.) -------- Originalnachricht -------- Betreff: Re: arbitrary code execution on unformatted usb stick Datum: 02.05.2020 18:22 Von: estellnb@elstel.org An: vince@vheuser.com Dear Vince I in deed mean that they have an internet connection channel for this offline computer. The computer does not have Wifi nor a LAN cable. What they were doing can not be explained by other means. I wonder how they transfer the data between the internet and that computer that should be separated physically from the internet. What I have observed can not be explained by malware unleashed at the time I have last plugged an USB stick. Elmar Am 02.05.2020 18:16, schrieb vince@vheuser.com: > Yes, I know the article and the long history building up that > capacity. You may recall I backed you up on the DANE support > discussion. What you are developing is a reliable secure software > system. > > The problem of compromised hardware is a different problem. Intel > builds back door circuits for NSA into their chips So I don't think > you'll build a laptop from them that NSA can't compromise. > > Unless you are engaging in international espionage or blowing the > whistle on them like Eric Snowden, I don't think they will compromise > their systems on low value targets. In that case, it doesn't make > much difference that they can get in, does it? > > On the other hand, a working DANE system can be used to keep our > conversation between us against most others except NSA and that alone > is worth something. Isn't it? Debian Security list members can't do > must about compromised hardware except be aware of it.... > >
[toc] | [prev] | [next] | [standalone]
| From | Elmar Stellnberger <estellnb@gmail.com> |
|---|---|
| Date | 2020-03-21 17:40 +0100 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zMPke-l0-33@gated-at.bofh.it> |
| In reply to | #5759 |
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
[toc] | [prev] | [next] | [standalone]
| From | "Rebecca N. Palmer" <rebecca_palmer@zoho.com> |
|---|---|
| Date | 2019-08-24 18:50 +0200 |
| Subject | Probably a false alarm Re: Have I caught a firmware attack in the act? Or am I just paranoid? |
| Message-ID | <yyHoJ-3fz-3@gated-at.bofh.it> |
| In reply to | #5649 |
On 15/08/2019 21:57, Rebecca N. Palmer wrote: > Paul Wise wrote: >> 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: I disassembled another Alcor stick (also 058f:6387 in its normal state, but several years older) and tried to trigger this deliberately by shorting pins (using pinout [0] and assuming pin 1 is marked by the corner spot, _not_ the orientation of the writing): Flash always "busy" [1] (shorting pins 47+48 to connector shell ground) just makes it not connect (presumably waiting indefinitely for the flash to become ready)... ...but shorting flash data pins to each other to turn reads to garbage (roughly 39-44 as that was the width of my screwdriver point - the full set is 37-44 + 27-34) *does* trigger the 058f:1234 state. This state persists after removing the short if the stick is left plugged in, but the normal 058f:6387 returns after unplugging and replugging it. Hence, I now consider the first stick to be broken, not malicious. Paul Wise wrote: > IMO proprietary software is worrisome in any context For Phison sticks, [2] is an at least partially open source firmware, including an option to deliberately break the update mechanism (preventing future changes, malicious or otherwise, without physically disassembling the stick), but it uses non-free tools to install. (I haven't tried it.) (non-trust warning: found via search and/or Wikipedia) [0] https://www.alldatasheet.com/view.jsp?Searchword=AU6983 [1] http://www.onfi.org/specifications [2] https://github.com/brandonlw/Psychson#running-no-boot-mode-patch
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | linux.debian.security
csiph-web