@MSGID: 1@dont-email.me> e0548e98
@REPLY: 1@dont-email.me> ce448b14
@REPLYADDR Don Y <blockedofcourse@foo.invalid>
@REPLYTO 2:5075/128 Don Y
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 1@dont-email.me>
@RFC-References:
<116ff07e-5e25-469a-90a0-9474108aadd3n@googlegroups.com> <pvl24i57aef4vc7bbdk9mvj7sic9dsh64t@4ax.com>
<f0afa198-e735-4da1-a16a-82764af3de4dn@googlegroups.com> <36534il81ipvnhog6980r9ln9tdqn5cbh6@4ax.com> 3@dont-email.me>
1@dont-email.me> 1@dont-email.me> 1@dont-email.me>
1@dont-email.me> 1@dont-email.me> 2@dont-email.me>
1@dont-email.me> 1@dont-email.me> 1@dont-email.me>
@TZUTC: -0700
@PID: Mozilla/5.0 (Windows NT 6.1; Win64; x64;
rv:102.0) Gecko/20100101 Thunderbird/102.2.2
@TID: FIDOGATE-5.12-ge4e8b94
On 5/3/2023 5:48 AM, David Brown wrote:

>>>> Give me the sources for Windows (Linux, *BSD, etc.) and I can
>>>> subvert all the state-of-the-art digital signing used to ensure
>>>> binaries aren`t altered.  Nothing *outside* the box is involved
>>>> so, by definition, everything I need has to reside *in* the box.
>>>
>>> No, you can`t.  The sources for Linux and *BSD /are/ all freely available.  
>>> The private signing keys used by, for example, Red Hat or Debian, are /not/ 
>>> freely available.  You cannot make changes to a Red Hat or Debian package 
>>> that will pass the security checks - you are unable to sign the packages.
>>
>> Sure I can!  If you are just signing a package to verify that it hasn`t
>> been tampered with BUT THE CONTENTS ARE NOT ENCRYPTED, then all you have
>> to do is remove the signature check -- leaving the signature in the
>> (unchecked) executable.
> 
> Woah, you /really/ don`t understand this stuff, do you?  Here`s a clue - ask 
> yourself what is being signed, and what is doing the checking.

Exactly.  You don`t attack the signature or the keys.  You BUILD A NEW KERNEL 
THAT DOESN`T CHECK THE SIGNATURE.  You attack (replace if you have access
to the sources -- as I stipulated above) the "what is doing the checking".
This is c.a.e; you likely have physical access and control of the device
(unlike trying to attack a remote system)

The binary is exposed UNENCRYPTED in the signed executable (please note my
stipulation to that, too, above).  The only thing preventing its execution
(if tampered -- or unlicensed!) is the signature check.  Bypass that in any
way and the code executes AS IF signed.

I design "devices".  Don`t you think if there was a foolproof way (by resorting
to "school boy techniques") to protect them from counterfeiting and tampering
that I would have already embraced that?  That EVERY computer-based product
would be INHERENTLY SECURED??

[There are ways that are far from theoretical yet considerably more
effective.  A signature check is easy to detect in an executing device
and, thus, elided.  Lather, rinse, repeat for each precursor level
of such protection.]

Please read what I`ve written more carefully, lest you look foolish.  Or,
spend a few years playing red-blue games and actually trying to subvert
hardware and software protection mechanisms in REAL products.  (Hint:
you will need to think down BELOW the hardware level to do so successfully
so you can bypass the hardware mechanisms that folks keep trying to embed
in their products)

 > Perhaps also ask yourself if /all/ the people involved in
security for Linux or 
> BSD - all the companies such as Red Hat, IBM, Intel, etc., - ask if /all/ of 
 > them have got it wrong, and only /you/ realise that digital
signatures on open 
> source software is useless?

The signature is only of use if the mechanism verifying it is tamperproof.
That`s not possible on most (all?) devices sold.  SOMEONE has physical
access to the device so all of the mechanisms you put in place can be
subverted.

*Ask* the Linux and BSD crowds if they can GUARANTEE that ALTERED signed code
can`t be executed on a system where the adversary can build and install their
own kernel.  Or, probe the innerworkings of such a device AT THEIR LEISURE/

> /Very/ occasionally, there is a lone genius that 
> understands something while all the other experts are wrong - but in most 
> cases, the loner is the one that is wrong.

In this case, you have clearly failed to understand what was being said.
So, don`t count yourself in with the "experts".

If the kernel loading the executable doesn`t contain code to validate the
signature  (and, if I have the sources for said kernel/OS then I can
easily *make* such a kernel) then the signature is just another unused
"section" in the BLOB.  Just like debug symbols or copyright information.

 --- Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.2.2
 * Origin: A noiseless patient Spider (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441