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!
