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.
>
>   "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?

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.
>
> 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?

>
> 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.

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?

>
> 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.

> 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?

> 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...

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

> <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.

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.

>
> 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?

Alex