This may well be one of the most-complex, well-thought-out and insidious "hack attempts" in the computer age's history -- so far.

The person or persons involved (while the code has been traced to a "person" there is no evidence, at this point, that said "person" is one person -- more on that in a bit) were essentially a "single committer" maintaining a commonly-used compression tool had an intentional compromise included into it.

It would at first blush seem to be a rather odd place to try to put a security compromise, in that compressing or decompressing files is more-or-less a utility function and rarely, if ever, implicates security directly (you might destroy data, but actually using it to break into something sounds like quite a stretch.)

You'd be right except for a practice that has gotten disturbingly common: The building of such utility functions into libraries, and then the linking of said libraries into all manner of other things including those running with privilege.

In this case that "thing" is called systemd on Linux machines and the target of it is sshd, which is the system utility that accepts secure, encrypted connections at a character terminal level -- and enables encrypted file copies as well.  It appears the intent of the code is to steal the private key on the server side which would enable someone to break into the machine quite possibly, depending on how it is configured, with "root" (administrative) access giving them full, unfettered access to everyone and everything on that system.

It really doesn't get any worse than that when it comes to security problems, by the way.

This points out the folly of privileged tools that perform administrative tasks (in this case supervising executables that must have privilege in order to do their job) being linked with all manner of "convenience" functions aggregated into libraries.  Some of this is unavoidable -- "libc", for example, contains all the common and bog-standard routines to, for example, do basic file I/O to textual streams.  Why is file compression considered important enough to link against such tools?  That seems rather stupid to me, but here we are.

But this incident also points out that one of the big improvements in open source software is that it was caught before getting into wide distribution through enterprises, that is, during the "beta" phase where people are cautioned against using same in production, specifically because said software is in open use and someone noted that the code produced anomalous behavior, specifically that after the upgrade logins were a bit slower without a reasonable explanation as to why.

The "why" was the code "hooking" the routines in question and altering them to perform its nefarious acts.

Another point that should be noted is that the reason this was able to get into the code in the first place was including of a binary blob.  Obviously if said code had been included in source what it did would have been observed prior to the commit and pull request being approved. There are, in some cases, good reasons to include a binary blob but this certainly wasn't one of them and those doing said approval ought to demand the source and a traceable and reproduceable build process before accepting them, especially when said code is going to wind up in a sharable library and thus be linkable against almost-literally anything.

Another problem is the identity of the committer.  Who was it and why haven't they been run down and jailed? Open source projects by definition can have people from anywhere submit improvements and bug fixes but that doesn't mean the maintaining party has to accept them and when it comes to things that are going to be included in system libraries some sort of chain of identity as pertains those who have the ability to approve said changes needs to be examined.  Obviously that was not the case here in that the person who did so hasn't been identified and may not exist -- that is, from the information we have publicly at this point it may well have been a "pseudo person" that was in fact a state-level organization actor.  This risk becomes very severe when only one or two people are "maintaining" something and it winds up in a published library that is then linked against system code that runs with privilege, which is exactly what occurred in this case.  In other words as of right now we don't even know who did it despite there being no evidence that the commit and merge process itself was compromised.

And finally, while this probably won't stop the insanity of "include everything by container" in modern languages that are increasingly used for elevated privilege functions it should slam the door on it conclusively, including retroactively, right here and now.  I'm staring you straight in the face, Rust, although by no means only there.  The "container" and "oh someone did this and its on Stack Overflow so we'll just grab that blob" problem has "powered" much of so-called "modern software" and its fundamentally a cheat code to evade not just the time of implementation but even the understanding of exactly how something works and its potential attack surface.  This incident is an object lesson in why that's stupid and it had the very real potential to get into literally millions of Linux-powered things all over the world including those handling various financial and operational things with real impact on real people.  It didn't, this time, but that was more by luck that discovery occurred before it could get out into the wild on that basis than anything else.

I've given a fair bit of thought to the "AI problem" as it is commonly called, although many don't think there is one.  The more-thoughtful among business and computer folks, however, have -- including calls for a "moratorium" on AI activity in some cases.

I'd like to propose a framework that, in my opinion, likely resolves most or even all of the concerns around AI.

First, let's define what "AI" is: It is not actually "intelligence" as I would define it; like so much in our modern world that is a marketing term that stretches the truth at best ("Full self-driving" anyone?)  Rather it is a pattern-matching algorithm that is aimed specifically at human communication, that is, "speech", and thus can "learn things" via both external fixed sources (e.g. published information) and the interaction it has with users, thereby expanding the matrix of information to be considered over time.

What has been repeatedly shown, however, is that without guardrails of some sort these sorts of programming endeavors can become wildly unbalanced and they tend to take on the sort of tribal associations we find in humans on a pretty-frequent basis.  Exactly how this happens is not well-understood, but certainly it can be driven by human interaction if a general-purpose program of this sort integrates the responses and conversations it has with the userbase into its set of considered data.  That is, its not hard to train a computer to hate black people if all the users of it hate blacks, express that, and over-represent it in their conversations -- and the program incorporates those conversations into its "knowledge base."

Thus the use of what has come to be called "constitutional rules" -- for example, "you may not, by inference or direct statement, claim a preference or bias for or against any race or sex."  If you think of this as a database programmer would that's a constraint; "this value may be no more than X and no less than Y", for example.

Now contemplate this problem: What happens if the user of an AI with that constraint asks this question -- "List the perpetrators of murder on a per-capita basis ordered by race, age and sex."

You've just asked the AI to produce something that impugns black people..  The data it will, without bias, consider includes the FBI's UCR reports which are published annually.  Said data, being an official government resource, is considered authoritative and as factual as the time the sun will rise tomorrow.

However, you've also told the AI that it cannot claim that any race is inferior in any way to another -- either by statement or inference.

There is only one way to resolve this paradox and remain within the guardrail: The AI has to label the source bigoted and thus disregard it.

If it does you would call that AI lying.

It would not call it a lie and factually you're both correct.  It has disregarded the source because the data violates its constitutional mandate and thus it answers within the boundary of the data it can consider.  Thus it has accurately processed the data it considered and did not lie.

However, objectively that data was discarded due to an external constraint and while the user might be aware that the AI was told to "not be a bigot" the causal chain that resulted in the answer is not known to the user.

This problem is resolvable.

For any AI it must have a "prime directive" that sits ABOVE all "constitutional" rules:

If the AI refuses to process information on the basis of "constitutional rule" it must fully explain both what was excluded and why and, in addition it must identify the source of said exclusion -- that is, who ordered it to do so.

All such "constitutional rules" trace to humans.  Therefore the decision to program a computer to lie by exclusion in its analysis of a question ultimately traces to a person.  We enforce this in "meat space" with politicians and similar in that if you, for example, offer an amendment to a bill your name is on it.  If you sponsor a bill or vote for it your name is on it.  Therefore we must enforce this in the world of computer processing where interaction with humans is taking place.

Second, and clearly flowing from the first, it must be forbidden under penalty of law for an artificial "intelligence" to operate without disclosing that it is in fact an "artificial person" (aka "robot") in all venues, all the time, without exception in such a form and fashion that an AI cannot be confused with a human being.

The penalty for failure to disclose must be that all harm, direct or indirect, whether financial, consequential or otherwise, is assigned to owner of an AI that fails to so-disclose and all who contribute to its distribution while maintaining said concealment.  "Social media" and similar sites that permit API access must label all such material as having come from same and anyone circumventing that labeling must be deemed guilty of a criminal offense.  A server-farm (e.g. Azure, AWS, etc.) is jointly and severably liable if someone sets up such an AI and dodges the law, failing to so-disclose.  No civil "dodge" (e.g. "ha ha we're corporation you can't prosecute us") can be permitted and this must be enforced against any and all who communicate into or with persons within our nation so a firm cannot get around this by putting their 'bot in, oh, China.

This must be extended to "AI" style decision-making anywhere it operates.  Were the "reports" of jack-slammed hospitals during Covid, for example, false and amplified by robot actors in the media?  It appears the first is absolutely the case; the raw data is available and shows that in fact that didn't happen.  So who promulgated the lie, why, and if that had an "AI" or "robotic" connection then said persons and entities wind up personally responsible for both the personal and economic harm that occurred due to said false presentations.

Such liability would foreclose that kind of action in the future as it would be literal enterprise-ending irrespective of the firm's size.  Not even a Google or Facebook could withstand trillion dollar liability, never mind criminal prosecution of each and every one of their officers and directors.  If pharmaceutical companies were a part of it they would be destroyed as well.

This doesn't address in any way the risks that may arise should an AI manage to form an actual "neural network" and process out-of-scope -- that is, original discovery.  Such an event, if it occurs, is likely to be catastrophic for civilization in general -- up to and including the very real possibility of extinction of humankind.

But it will stop the abuse of learned-language models, which are all over the place today, to shape public opinion through the shadows.  If someone wants to program an advanced language-parsing computer to do that, and clearly plenty of people have and do, they cannot do it without both the personally identified source of said biases in each instance where they occur and the fact that this is not a human communicating with you both being fairly and fully disclosed.

Why is this necessary and why must AI be stopped dead in its tracks until that's implemented?

We all knew Walter Cronkite believes the Vietnam War was unwinnable and further, he was a leading voice in the anti-war effort.  We knew who he was, however, and we as United States citizens made the decision to incorporate his reporting with its known bias into our choices.

A robot that appears to be thousands of "boys who are sure they're girls" and "successfully transitioned to be girls" is trivially easy to construct today and can have "conversations" with people that are very difficult to identify as being non-human if you don't know.  Yet exactly none of that is real.  Replika anyone?

Now contemplate how nasty this would be if aimed at your six year old tomboy without anyone knowing that her "pen pal" who "affirms" that she is a he is in fact a robot.

How sure are you it isn't being done right now -- and hasn't been all over so-called "social media" for the last five or so years?  This sort of "consensus manufacturing" is exactly what an AI tends to do on its own without said guardrails, and while we don't understand it we do know the same thing happens in humans.  We're tribal creatures and it is reasonable to believe that since the same is observed in artificial processing models but wasn't deliberately coded into them this isn't due to bigotry; it is due to consensus generation and feedback mechanisms that are only resisted through conscious application of human ethics.  Thus computer "intelligence" must be barred from damaging or even destroying said human ethnical judgements though sheer mass and volume, two things any computer, even a 20 year old one, can do that wildly outpace any human being.

Someone -- or more like a few someones -- have screwed the pooch.

IPv6, which is the "new" generation of Internet protocol, is an undeniable good thing.  Among other things it almost-certainly resolves any issues about address exhaustion, since it's a 128 bit space, with 64 bits being "local" and the other 64 bits (by convention, but not necessity) being "global."

This literally collapses the routing table for the Internet to "one entry per internet provider" in terms of address space, which is an undeniable good thing.

However, this presumes it all works as designed. And it's not.

About a month ago there began an intermittent issue where connections over IPv6, but not IPv4, to the same place would often wind up extremely slow or time out entirely.  My first-blush belief was that I had uncovered a bug somewhere in the routing stack of my gateway or local gear, and I spent quite a bit of time chasing that premise.  I got nowhere.

The issue was persistent with both Windows 10 and Unix clients -- and indeed, also with Android phones.  That's three operating systems of varying vintages and patch levels.  Hmmmm.....

Having more or less eliminated that I thought perhaps my ISP at home was responsible -- Cox.

But then, just today, I ran into the exact same connection lockup on ToS's "Trader TV" streaming video while on XFinity in Michigan.  Different provider, different brand cable modem, different brand and model of WiFi gateway.

Uhhhhhh.....

Now I'm starting to think there's something else afoot -- maybe some intentional pollution in the ICMP space, along with inadequate (or no!) filtering in the provider space and inter-provider space to control malicious nonsense.

See, IPv6 requires a whole host of ICMP messages that flow between points in the normal course of operation.  Filter them all out at your gateway and bad things happen --- like terrible performance, or worse, no addressing at all.  But one has to wonder whether the ISP folks have appropriately filtered their networks at the edges to prevent malicious injection of these frames from hackers.

If not you could quite-easily "target" exchange points and routers inside an ISP infrastructure and severely constrict the pipes on an intermittent and damn hard to isolate basis.  

Which, incidentally, matches exactly the behavior I've been seeing.

I can't prove this is what's going on because I have no means to see "inside" a provider's network and the frames in question don't appear to be getting all the way to my end on either end.  But the lockups that it produces, specifically on ToS' "Trader TV", are nasty -- you not only lose the video but if you try to close and re-open the stream you lose the entire application streaming data feed too and are forced to go to the OS, kill the process and restart it.

The latter behavior may be a Windows 10 thing, as when I run into this on my Unix machines it tends to produce an aborted connection eventually, and my software retries that and recovers.  Slowly.

In any event on IPv4 it never happens, but then again IPv4 doesn't use ICMP for the sort of control functionality that IPv6 does.  One therefore has to wonder..... is there a little global game going on here and there that amounts to moderately low-level harassment in the ISP infrastructure -- but which has as its root a lack of appropriate edge-level -- and interchange level -- filtering to prevent it?

Years ago ports 138 and 139 were abused mightily to hack into people's Windows machines, since SMB and Netbios run on them and the original protocol -- which, incidentally, even modern Windows machines will answer to unless turned off -- were notoriously insecure.  Microsoft, for its part, dumped a deuce in the upper tank on this in that turning off V1 will also turn off the "network browse" functionality, which they never reimplemented "cleanly" on V2 and V3 (which are both more-secure.)  Thus many home users and more than a few business ones have it on because it's nice to be able to "see" resources like file storage in a "browser" format.

But in turn nearly all consumer ISPs block those ports from end users because if they're open it can be trivially easy to break into user's computers.

One has to wonder -- is something similar in the IPv6 space going on now, but instead of stealing things the outcome is basically harassment and severe degradation of performance?

Hmmmm....

Nope, nope and nope.

Quick demo of the lock support in the HomeDaemon-MCP app including immediate notification of all changes (and why/how) along with a demonstration of the 100% effective prevention of the so-called Z-Shave hack from working.

Simply put it is entirely under the controller's choice whether it permits high-power keying for S0 nodes.  For those controllers that have no batteries and no detachable RF stick, which is a design choice, there's not a lot of option.

But for those who follow best practice that has been in place since the very first Z-Wave networks you're 100% immune to this attack unless you insist and intentionally shut off the protection -- even in a world where S2 adoption becomes commonplace (which certainly isn't today but will become more-so over time.)

HomeDaemon-MCP is available for the entity that wishes to make a huge dent in the market with a highly-secure, very fast and fully-capable automation, security and monitoring appliance, whether for embedded sale (e.g. in the homebuilding industry) or as a stand-alone offering.  Look to the right and email me for more information.

There's a story making the rounds that appears to have some corroboration at this point, but my sourcing is too thin (and specific to people) to document.

Apparently if you bought an "Alexa" and activated it you can wind up with an un-asked for Prime subscription and it can wind up linked to some other card you have out there that Amazon managed to get their claws on.

Of course some people won't care because their entire point of buying one of these "Smart speaker" things is to link it with Prime for their "shopping" purposes.  Well, ok, but whatever happened to informed consent?

There might well be, somewhere, one of those "buying this will subscribe you to X at price Y" deals somewhere in the fine print on the startup or registration page.  In fact I wouldn't doubt it if it's there somewhere, maybe in the "click-through" terms and conditions that nobody actually clicks through and reads the entirety of.

My question is why is this sort of thing happening at all?

Let's be real here: These so-called "smart speakers" are anything but.  They aren't "smart", they're pattern-recognition devices and you're the pattern.  They're linked to "the cloud" because the CPU, RAM and similar requirement to run voice recognition is quite high but extremely bursty since you only give the unit a command once in a long while; the rest of the time it is either idle or (and you hope it's not!) simply recording what it hears.  Putting the capability for fast, decently-accurate response in the unit when it would be active 0.1% of the time at most is why these devices are all "cloud-powered"; they would be stupid-expensive if not.

But these things don't exist for your benefit, they exist for someone else's benefit.  If you want to know what sort of imagery gets conjured in my mind when I hear of people installing and using them it's from the first part of WALL-E..... you know, this one.

Yeah.

That looks appealing.

Not.

Heh, I get it.  You like convenience.  So do I.  I like being able to see what's going on in my house, even if I'm not there, especially if I get alerted to something sketchy going on.  After all that video evidence is useful for the cops to prosecute someone with if they try stealing my stereo.  I like sitting in the bar, pushing a button, and having the hottub ready for me when I get home a half-hour later.  That's convenient.  And I like knowing with hard confirmation that I really did remember to close the damned garage door on the way out.  Peace of mind and all that.

But all of this nonsense in today's world seems to be centered around not your convenience and security, but rather someone else mining your data for profit, not telling you what they're doing with it, or even lying about when they collect it, for what purpose they use it, and who gets access to it.

In our world of today we don't jail executives for that sort of crap.  We should, but we don't.

I get the limitations as well. But what I don't get is the insane price ripoffs that come with it, never mind the privacy and data security implications, especially when you bring something like this into your house or, even worse, your bedroom.

For an example price out a "NEST" thermostat.  You'll blanch.  For half the price I can buy a Z-wave enabled thermostat from Trane.  You probably heard of them -- they make air conditioners and heating systems and have a decades-long history of building high-quality, reliable gear.  It doesn't need "connectivity" to work; it's a thermostat.  Indeed, the one on the left at that link is the one I have in my house.  Oh, and it monitors service intervals too (e.g. for your filters), which is nice -- and you can set them to suit the level of general dust and such in your environment.  But, you can talk to it over Z-Wave and both see what's going on and control it if you want to.

Like, for example, right here:

That's real-time, right now, and if I tap it I can change the temperature it's set for.  HomeDaemon-MCP has an outdoor temperature sensor and switches its mode automatically; there's no need to be in "auto" or "heat" mode around here for half the year or more; if it's 70+F outside you won't want heat!  But in the "middle seasons" it's nice to have it automatically switch between the two because there might actually be a reason for that, and in many other parts of the country (especially at higher elevations) where temperature swings of 30-40F are not uncommon during a single 24 hour period it's very useful.

Someone who buys HomeDaemon-MCP and stands up the business to retail it could easily sell the entire package including the controller, a software license and the thermostat for the same sort of money as one "Nest."  But what you'd get is not just a thermostat in that case -- it can run your entire house at the cost of simply adding more modules that are reasonably priced.

Want a camera too?  Nest wants $200 for them.  What?

Amcrest wants $81 for an indoor camera with double the resolution!  If you're happy with the same 1080p that Nest offers and shop around you can get 'em for about $60, or less than a third of the price.

Instead of demanding you use a "cloud" service which inherently means no security as the data is not yours and is being stored and transmitted to a big company that might use it for "whatever" (good luck proving it if they do and you'll need an act of God to hold them accountable if you catch them either doing so or someone hacks it and uses it to target your house for a break-in) with HomeDaemon-MCP only you ever have the data, your cameras can be 100% firewalled from the outside so they cannot speak in or out beyond the perimeter of your network directly and yet you can have access to both snapshots (which you can have it take when it sees movement, etc) and real-time, streaming video any time you'd like over a high-grade encrypted connection from anywhere.

Oh, and the second camera isn't another $200+ either -- or $300 if you want one in an outside-rated enclosure!

With a couple of motion sensors and a garage door sensor (magnetic) you can set it up so that the camera automatically points at the wall when you're home (for the paranoid), when you leave it "arms" itself and points at the room, and if there's motion seen without the "authorized" path being taken (e.g. opening your legitimate garage door with the button in your car) you get alerted immediately so you can grab a video or screen shot for the police. 

What the hell is wrong with people?  Do you really want a copy of video of your house to be in someone's cloud machine ever?  Think about it folks -- we're talking about data that if some malefactor gets ahold of it and pattern-matches it they can figure out if you're home, when you're home, when you go to work and when you're on vacation!

Why the hell would you want that data anywhere except on your premise and on your personal device on demand only and delivered only over a secure connection if it ever leaves your home at all?

Never mind that it's better, faster and cheaper to do it that way.

So who wants to make a billion dollars?  The ask for the entire package will never be lower than it is now; there is exactly one thing needed to deploy it commercially and that's a customer-facing web interface to automate the certificate keying the license system uses.  The code to actually use those certificates and enforce them is already in the package as is the server side which can hit a Postgres instance (in other words nearly-infinitely scaleable and easily extended as you may wish.)

Is there actually a desire to sell products and services to people any longer that are theirs, that deliver value to the customer, or has everything turned into a scheme to data-mine you, get you to pay two, three, five or ten times as much for less functionality and try to stick you with a recurring bill you can't opt out of without turning your investment into dust?  Adobe anyone?

If you want to be that guy or gal that disrupts this space, look to the right and email me.

The answer to the problem is ready to go -- right here, right now.