• arbitrary code execution on unformatted usb stick

    From Elmar Stellnberger@21:1/5 to All on Sat Apr 25 15:40:01 2020
    This is a multi-part message in MIME format.
    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

    IyBtYW4gNyB1ZGV2CiMgY2F0IC9zeXMvYnVzL3VzYi9kZXZpY2VzLzItMS9zZXJpYWwKIyBj YXQgL3N5cy9idXMvdXNiL2RldmljZXMvMi0xL3Byb2R1Y3QgLT4gVVNCIE1hc3MgU3RvcmFn ZSBEZXZpY2UKI1NVQlNZU1RFTT09InVzYiIsIEFUVFJTe3NlcmlhbH09PSIwMDAwMDAwMDAw MDJDNyIsIE1PREU9IjA2NjAiLCBHUk9VUD0iMTAwIgpTVUJTWVNURU09PSJibG9jayIsIEFU VFJTe3NlcmlhbH09PSIwMDAwMDAwMDAwMDJDNyIsIEVOVntQQVJUTn0hPSIxIiwgU1lNTElO Sys9ImJsdWV1c2IlbiIsIE1PREU9IjA2NjYiCgo=

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Elmar Stellnberger@21:1/5 to All on Sat Apr 25 15:50:02 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Elmar Stellnberger@21:1/5 to All on Sat May 2 17:10:02 2020
    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!






    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Elmar Stellnberger@21:1/5 to All on Sat May 2 17:00:02 2020
    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!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)