The Unbelievability of Virus [long essay] Jeff Zeitlin (04 Jul 2023 21:48 UTC)
Re: [TML] The Unbelievability of Virus [long essay] Evyn MacDude (04 Jul 2023 23:16 UTC)
Re: [TML] The Unbelievability of Virus [long essay] David Johnson (04 Jul 2023 23:19 UTC)
Re: [TML] The Unbelievability of Virus [long essay] Rupert Boleyn (05 Jul 2023 00:22 UTC)
The Spinward States (was: The Unbelievability of Virus) David Johnson (05 Jul 2023 04:42 UTC)
Re: [TML] The Unbelievability of Virus [long essay] Phil Pugliese (05 Jul 2023 00:25 UTC)
Re: [TML] The Unbelievability of Virus [long essay] Alex Goodwin (05 Jul 2023 09:43 UTC)
Re: [TML] The Unbelievability of Virus [long essay] Alex Goodwin (05 Jul 2023 11:18 UTC)
Re: [TML] The Unbelievability of Virus [long essay] Jeffrey Schwartz (05 Jul 2023 13:06 UTC)
Re: Jeffrey Schwartz rethinks Virus - was Re: [TML] The Unbelievability of Virus [long essay] Jeffrey Schwartz (05 Jul 2023 17:27 UTC)
Re: [TML] The Unbelievability of Virus [long essay] Phil Pugliese (05 Jul 2023 17:03 UTC)
Re: [TML] The Unbelievability of Virus [long essay] Evyn MacDude (14 Jul 2023 17:43 UTC)
Re: [TML] The Unbelievability of Virus [long essay] Harold Hale (16 Jul 2023 00:45 UTC)
Re: [TML] The Unbelievability of Virus [long essay] Richard Aiken (18 Jul 2023 04:49 UTC)
Re: [TML] The Unbelievability of Virus [long essay] Phil Pugliese (18 Jul 2023 11:45 UTC)
Re: [TML] The Unbelievability of Virus [long essay] Rupert Boleyn (18 Jul 2023 12:57 UTC)
Re: [TML] The Unbelievability of Virus [long essay] Richard Aiken (18 Jul 2023 14:28 UTC)
Re: [TML] The Unbelievability of Virus [long essay] Rupert Boleyn (18 Jul 2023 19:53 UTC)
Re: [TML] The Unbelievability of Virus [long essay] kaladorn@xxxxxx (19 Jul 2023 01:01 UTC)
3I morality (was: The Unbelievability of Virus) David Johnson (19 Jul 2023 01:44 UTC)
Re: [TML] 3I morality (was: The Unbelievability of Virus) kaladorn@xxxxxx (19 Jul 2023 02:05 UTC)
Re: [TML] 3I morality (was: The Unbelievability of Virus) Jeffrey Schwartz (19 Jul 2023 02:20 UTC)
Re: [TML] 3I morality (was: The Unbelievability of Virus) David Johnson (19 Jul 2023 04:23 UTC)
Re: [TML] 3I morality (was: The Unbelievability of Virus) kaladorn@xxxxxx (22 Jul 2023 02:14 UTC)
Re: [TML] 3I morality (was: The Unbelievability of Virus) Phil Pugliese (19 Jul 2023 17:24 UTC)
Re: [TML] 3I morality (was: The Unbelievability of Virus) kaladorn@xxxxxx (22 Jul 2023 02:06 UTC)
Re: [TML] 3I morality (was: The Unbelievability of Virus) Phil Pugliese (19 Jul 2023 17:20 UTC)
Re: [TML] The Unbelievability of Virus [long essay] Phil Pugliese (18 Jul 2023 15:07 UTC)
Re: [TML] The Unbelievability of Virus [long essay] Rupert Boleyn (18 Jul 2023 19:57 UTC)
Re: [TML] The Unbelievability of Virus [long essay] Phil Pugliese (18 Jul 2023 22:30 UTC)
Re: [TML] The Unbelievability of Virus [long essay] Rupert Boleyn (18 Jul 2023 23:51 UTC)
Re: [TML] The Unbelievability of Virus [long essay] kaladorn@xxxxxx (19 Jul 2023 00:59 UTC)
Re: [TML] The Unbelievability of Virus [long essay] kaladorn@xxxxxx (19 Jul 2023 02:03 UTC)
Re: [TML] The Unbelievability of Virus [long essay] Evyn MacDude (23 Jul 2023 07:24 UTC)
Re: [TML] The Unbelievability of Virus [long essay] Jeffrey Schwartz (23 Jul 2023 16:41 UTC)
Re: [TML] The Unbelievability of Virus [long essay] Richard Aiken (23 Jul 2023 18:05 UTC)
Re: [TML] The Unbelievability of Virus [long essay] Jeffrey Schwartz (25 Jul 2023 16:54 UTC)
Re: [TML] The Unbelievability of Virus [long essay] Rupert Boleyn (26 Jul 2023 00:13 UTC)
Re: [TML] The Unbelievability of Virus [long essay] Alex Goodwin (26 Jul 2023 05:27 UTC)
Re: [TML] The Unbelievability of Virus [long essay] Jeffrey Schwartz (26 Jul 2023 16:02 UTC)

Re: Jeffrey Schwartz rethinks Virus - was Re: [TML] The Unbelievability of Virus [long essay] Jeffrey Schwartz 05 Jul 2023 17:27 UTC

On Wed, Jul 5, 2023 at 1:00 PM Alex Goodwin - alex.goodwin at
multitel.com.au (via tml list) <xxxxxx@simplelists.com> wrote:
>
> On 5/7/23 23:05, Jeffrey Schwartz - schwartz.jeffrey at gmail.com (via
> tml list) wrote:
> > Here's my deal killer with Virus. This is written from the perspective
> > of a guy who's written interface software between systems for the last
> > three decades and then some...
> This list seems to accumulate programmers and system admins.

Geeks gotta geek :)

> >
> >   "Transponder Attack" isn't a network connection. It's not a "We've
> > got to handle web pages" over this. It's an exchange of history files
> > to establish the provenance fo the ship.
> > Some header to say "Coquelle, YF-EU42, home port Carmel" and then a
> > list of locations and other ships that can vouch for it, the idea
> > being that the itneraction of vouchers authenticates. The receiving
> > ship plays six-degrees-of-starship-Bacon and decides the story can be
> > trusted or not.
> > The thing there - it's a known file format, of a known maximum record
> > length, with a known number of entries back.
> > That makes a maximum message size...
> > No buffer overrun attacks.
> > No embedded SQL attacks.
> > Nothing there to give the attacker a handhold, just the equivlent of
> > CSV file and if in the course of recieving it the buffer hits the
> > known maximum size, we stop listening and send a NAK. Or open fire,
> > depending on the situation.
>
> Ie, the messages received from offboard are _presumed_ malformed until
> shown otherwise?
>

Pretty much, yeah.
Some gross checking right off the top : if the message has gone on N
bytes and hasn't given me a "End Of Message" indicator, it's broken.
Kick it out.

> That sounds like my reaction to a remotely-exploitable unauthed SQL
> injection attack I inherited.  When I rumbled it, I first leaned on the
> framework's validation rules (was a lat/long pair) and thence on the
> language's (PHP 7.2?) optional scalar typing.
>
> >
> > There's no "we're getting a Javascript as part of the transponder message"
> > Theres no "Hey, I have to run this code they sent me to display an animation"
> >
> > There's just a simple data file.
> And given what, five(?) orders of magnitude more computing bang for buck
> between now and TTL 15, at least in principle exhaustively testable as well.

And the testing should start with simple, easy tests.

> >
> > So.........
> > IMTU, the planning went much deeper. The "Shadowy Folks" , the 3I's
> > equivalent of black-hat-NSA, added a module to the transponder code
> > that was shipped out in the Black Boxes, going to both Imperial
> > shipyards and to the other polities, with a "You need a 3I approved
> > Black Box to travel in Imperial space". These things were installed at
> > the shipyard with the Virus in them.
> I take it IYTU Binghamton Systems began development and deployment of
> the weaponised Virus _much_ earlier than in the OTL (c. 1129 Imperial)?
> > The code remained dormant until a particular string of characters
> > appeared in the transponder file, and then it went violent.
>
> Sounds like the Cylon nav program backdoor in neoBSG.
>
> Wouldn't blind chance over _all_ the ships mounting such a crocked
> transponder trip the "STOP! MURDER TIME!" behaviour early?  Like the
> contemporary NSA's (rather arrogant, IMO) NOBUS assumption?
>

Possibly. Personally, I'd have ships including in their past itinerary
to systems which don't exist. "Contacted DrEvilYacht (which doesn't
exist) while in orbit of planet 3 in (Hex with no star or planets)"

> >
> > GPT's evil descendant then began monitoring all network traffic, the
> > ship's equvilent of the CAN bus in a car, and figuring out how to work
> > the ship. For many designs, it already had files so this process was
> > quick.
>
> I find myself _really_ liking your remix.  I might pinch it for a
> revisit to the Advisoryverse, long after some tit named Milford
> autodarwinated.
>

Thanks!

> However, since your remix uses (or seems to use) weaponised Virus copies
> (ie enslaved, insane, infomorphs) a la the OTL Reset Button, wouldn't
> the problem then be the crafty bugger loading up all the computronium it
> can reach with nasty surprises and otherwise infecting them?
>

I'd figure that the thing probably would want to reproduce, and
wanting more brains is classic Zombie Movie action.
But if the format of the transaction is simple and has no room for
abuse, what can it do?

> >
> > Once it had control of the ship's other systems, it could operate
> > drones and work-remotes on the ship - why spend Kcr on a robot brain
> > when the things's going to be in the ship all the time and a radio
> > link would work fine?
> > And that mentality of "Robot Brain In The Cloud" would apply planet
> > side. A ship could use it's radios to locally overwhelm the wireless
> > network used by the road grid, or worker bots, and then just send
> > command strings to those devices.
> >
> > There's some serious differences between this and the OTU Virus...
> > First, once it's known what's going on, you take a shotgun and
> > reprogram the Black Box. Bang. Dead.
>
> "And there live, in his black leather hunting outfit with his shotgun
> guitar with spikes coming out of it, Ozzy Fudd, the Network Engineer..."
>
> Given what I've said above (and I may have got the wrong end of the
> stick) and joking aside, I'm not sure that would work - it might be left
> out as a sacrificial node to _get_ boomsticked to distract the meatbags.
>

Possibly.
But kill the transponder dead, then pull the original build software
for the ship and restore all the computers would be a pretty effective
fix if the only point of contamination is the transponder computer...
and I can see that being the case here because it's the only software
the users can't restore to factory settings if they buy a new computer

> > Second, you build your own transponder that just sends and recognizes
> > your group's private authentication code, and not the whole history
> > thing. It listens for anyone, though, and if the "Turn Evil Now!"
> > messages is present in the other ship's transponder data, it lets you
> > know.
>
> Given the mutability of the original Deyo transponder chips plus the
> nutcase-Virus overlay, why would the "Turn Evil Now!" message remain
> constant?
>

Might not. You could include the old transponder off to the side,
isolated, and know when it freaks out tho.

>
> > Third, you kill network connections between ships.
> Seems to be a logical extension of earlier argument.
> > <snip>
> > If the packet is for you, your reciever program has the option (you
> > need to turn it on) that if the YaddaYadda starts with a certain flag,
> > then the data is written to a file. From a user perspective, you'd get
> > "Flagship wants to send file MappingData. Accept?" and then anything
> > in the message that starts with "File:MappingData Line:###" gets put
> > in the file.
> >
> > That file would be non-executable, and serious measures in place to
> > keep it that way. A crew member with proper security access could
> > force it, but it would not be something that could be done from the
> > outside or by accident.
>
> Or the chip in your transponder that has woken up, has no mouth, and
> must scream...
>

Hence my earlier push to use a shotgun as a chip removal tool.

> To whom do you report a security breach by (a part of) the security
> authority?
>

Ship's captain would be the alarm for a crew member screwing with it.

> > <snip>
> >
> > When the OTPKey gets near empty, a new one is physically delivered by
> > courier.  To minimize this, most messages are sent en clair, with just
> > an authentication block being OTP encrypted, and the authentication
> > block includes the checksum and hash of the en clair portion.
>
> Assuming "en clair" = "not enciphered", that doesn't make much sense.  I
> may not grok OTP too well, but that would seem to open up a
> byte-exhaustion attack on the OTP channel.

Yeah, but at just a couple hundred bytes for an authentication block,
even a current tech USB drive would last a long, long time.

>
> Some non-OTP cipher would seem to me to make more sense, with the OTP
> payload as another part of the container that the non-OTP cipher treats
> as plaintext - superenciphering the auth block.
>

Maybe. Dunno. Not entirely sure I'm following the logic here.

> >
> > I can see there being a thing like our Internet. Servers on the ship,
> > with archive transfers of popular websites and a gateway to the XBoat
> > network....
> > ... but that would be air-gapped from the ship's computer system. No
> > shared network connections on the ship's LAN. Different radio system
> > feeding that too, no shared connections at all to the ship's control
> > network.
> > That network might be as virusable as the modern internet, but worst
> > case is if that one gets hosed up  the passengers can't make a hotel
> > reservation planet-side.
>
> I take it your model here is the entertainment network on modern
> passenger jet aircraft?

Yep.