Path: ...!feeds.phibee-telecom.net!weretis.net!feeder6.news.weretis.net!panix!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!69.80.99.22.MISMATCH!local-2.nntp.ord.giganews.com!nntp.supernews.com!news.supernews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 08 Apr 2024 16:10:53 +0000
From: John Larkin <jl@997PotHill.com>
Newsgroups: sci.electronics.design
Subject: Re: German state gov. dicthing Windows for Linux, 30k workers migrating.
Date: Mon, 08 Apr 2024 09:09:10 -0700
Organization: Highland Tech
Reply-To: xx@yy.com
Message-ID: <bh581jdslld4m8ut5jo3r1j7ljapgkp866@4ax.com>
References: <uuqirt$6kgh$1@solani.org> <jgp21jl76nk0c3064ss3pbfq5pboav93hp@4ax.com> <5qb31j9c2ia9a6h2fr50onqa2vp4d4bsfm@4ax.com> <3hf31j9d0uq5b9imcq94b495c3hclbjv79@4ax.com> <1qrnmxu.99joma1j6s84iN%liz@poppyrecords.invalid.invalid> <uuuto0$2vka9$1@dont-email.me> <1qroud8.1ot9y7y1yrh1ywN%liz@poppyrecords.invalid.invalid> <uv13tc$3jc5k$1@dont-email.me>
X-Newsreader: Forte Agent 3.1/32.783
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 161
X-Trace: sv3-fx0XFXUwtBYt/m9bZsIqTtYUNw7zx/hYdGsDMUtSCklAqNMs2Mh93QbpYOu8RvObXef/6HK+NqJO0Jg!nUUgpOdtxnvGeEvxobmQs+q9XUyEb1yBjIYf9RX8kvYLV0irg0NJ/M1WfeR0nHL7s88VHwiHdgUF!VOtp8g==
X-Complaints-To: www.supernews.com/docs/abuse.html
X-DMCA-Complaints-To: www.supernews.com/docs/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
Bytes: 9576

On Mon, 8 Apr 2024 08:53:11 -0700, Don Y <blockedofcourse@foo.invalid>
wrote:

>On 4/8/2024 1:38 AM, Liz Tuddenham wrote:
>> Don Y <blockedofcourse@foo.invalid> wrote:
>> 
>>> ...  It costs relatively little to probe (and fingerprint)
>>> every accessible IP.  Then, throw a set of exploits *already* deemed LIKELY
>>> to compromise such a system at it and note the results.  The process can
>>> be automated (and likely would be given the sheer number of potential
>>> targets!)
>> [...]
>> 
>> I was thinking of a slightly different approach from the usual one.
>> With automated coding and decoding it is a relatively simple matter to
>> concatenate various processes such as:
>> 
>> Direct encipherment
>> Rearrangement by character or block
>> Insertion of dummy characters
>> Codes
>> Languages
>> 
>> Each of these could be broken individually, but used in succession they
>> become much more difficult.  This would be a system that was suitable
>> for small organisations where the daily arrangements could be
>> distributed by a separate communication -- for instance:
>> 
>> Today:  Shift by 5 letters - Reverse each block of 11 letters - Insert a
>> random character every 3rd and 17th position - shift back 7 letters -
>> Represent every 19th letter with it's Vail Cipher equivalent -  Arrange
>> letters on a 12 x 12 grid in rows and read them out by column.
>> 
>> Tomorrow:  Double a character every 7th position - Arrange letters on a
>> 10 x 19 grid in rows and read them out by columns -Represent every 13th
>> letter with its ASCII equivalent -Reverse alternate blocks of 11
>> characters - Shift back 3 letters - Add a random character every 12th
>> position -  Arrange letters on a 9 x 17 grid in rows and read them out
>> by columns
>> 
>> Anyone trying to break into the system, even if they could guess at some
>> of the elements or intercept one of the distributions, would be faced
>> with a lot of work for very small returns.  The elements could be
>> changed around and new ones added to the repertoire quite easily.
>
>Where is the cleartext version stored?  Or, are you perpetually re-recoding
>the data (so the cleartext never exists on the store)?
>
>Are you relying on some third party in any way (in which case, his
>system expands the attack surface).
>
>What happens if I hack your system and mirror your display elsewhere?
>
>What if I coerce some staff member to telling me something they
>shouldn't (by claiming to be someone's little old grandmother who
>forgot his phone number, birth date, etc; "Could you please give
>it to me, Deary?").
>
>Or, some stupid staff member who doesn't realize that it's NOT a good
>idea to send around a memo to the department staff with a list of
>every employee's birthdates.  (SWMBO had to intercept a memo that
>listed every department member's SSN!  What idiot thought THAT
>was a good idea?)
>
>Is there a way to pass information OUT of your organization?
>How do you ensure that cleartext is always re-encoded before being
>distributed to other parties?  After all, the people who consume
>that information need to see it in its unencrypted form...
>
>Plus, security is more than just protecting your secrets.  What if I
>prevent you from accessing that store -- by deleting it, encrypting it
>(with MY key), or simply eating up the bandwidth that you need to
>access it?
>
>Or, the early days where the adversary's goal was just to crash your system
>or render it unbootable.  Clearly, these aren't activities that you would
>WANT someone to be able to undertake; you would want to *secure* your
>system AGAINST them!
>
>[Hard to imagine anyone NOT running a web browser and using "web apps".
>How secure is that option?  (Firefox is ~20+M SLoC!)  MULTICS was
>considered "bloated" inspiring the creation of "UNIX".  MULTICS was
>~300K SLoC; Linux is ~50M SLoC!  How many millions of lines of code
>are involved in your accessing this USENET post?]
>
>I've protected my *switch* from folks wanting to impose "lightning strikes"
>on the "exposed" network drops.  Because failing to include such protection
>would mean a key component (the switch) could be subverted from a single
>attack point.
>
>My neighbor's alarm system is completely wireless (selling point:  no
>nasty wires to run through your home).  But, I could (illegally) subvert
>it with an RF jammer.  Of course, the legality of that jamming wouldn't
>bother me if I was already intent on breaking the law to steal from him.
>
>>> Can you enumerate all of the potential security vulnerabilities that
>>> you *have*?  Today?  Tomorrow??
>> 
>> No, but I can make life very difficult for would-be hackers in the hope
>> that they will turn to easier targets with better rewards.  For some
>
>"Standing out" is one way to get hackers' (i.e., individuals) attention.
>     "Why is this person/entity going to such lengths to make their
>      systems/data so difficult to access?"
>You won't fall to a boilerplate attack but may merit a *focused*
>attack by someone who looks at you as a "challenge" (and, possible harbinger
>of new defenses to which they will have to adapt).
>
>Being different also sacrifices anonymity (presumably, privacy has SOME value
>to you).  When I had a non-stealth server, I did my best to hide its
>configuration by changing all the banner messages, etc.  Of course, that
>made it stand out -- because it WASN'T one of the (relatively few) known
>system characterizations at the time.
>
>[I also learned that these obvious changes don't prevent the system
>from being identified as there are all sorts of characteristics that
>can be profiled/fingerprinted to deduce what's running, there]
>
>> years I have had to store databases of personal information on computers
>> that are connected to the Web, so I have given the problem a lot of
>> thought.  Without access to the decoding programs (which are in an
>> obsolete format running on an obsolete OS) there is little chance of
>> anyone else decoding the information.
>
>So, what do you do when *I* encrypt your encoded data?  Or, bring down
>the (remote) system that is hosting it?
>
>You also would be surprised at how much information "leaks" from naive
>encoding strategies.  E.g., if you know (or suspect) the format of the
>content, you can often deduce the coding algorithm.
>
>E.g., sign up for your service and then watch to see how you store
>my information "remotely".  Now I know what that information maps to.
>Or, go hunting for something that I know (or suspect) is already encoded
>in your data. And, I know the distribution of letters/words in prose,
>names, etc.
>
>History is littered with failed encryption/security algorithms that seemed
>to be unbreakable.  Because people rise to the challenge of subverting
>them!  ("That's where the money is" -- Willie Sutton)
>
>Who'd have thought of breaking into a vehicle's CAN network (by forcefully
>removing something easily accessible -- like a headlight!) to impress the
>"Unlock doors" command on the bus?  Gee, maybe you should design the
>system so it doesn't blindly assume every message is legitimate?!
><https://www.autoblog.com/2023/04/18/vehicle-headlight-can-bus-injection-theft-method-update/>
>
>Intentional reprogramming of pacemakers?  (Why would anyone deliberately
>do that?)
><https://www.ahajournals.org/doi/full/10.1161/CIRCULATIONAHA.118.037331>
>
>Airline flights?
><https://www.theregister.com/2024/02/03/researchers_remotely_exploit_devices_used/>
>
>What are the chances "one of many" solutions has addressed all of the
>vulnerabilities that affect its implementation?

No amount of fiddling will ever fix a fundamentally bad design.

We need a new, totally hardware protected, computer and OS design.