Observer 0.24.1

Observer 0.24.1.

Security fix for Windows (0.24.0 and earlier)

Windows only. The Linux package is not affected with its default path: /etc can be written only by root, and the package creates /etc/observer for the account the service runs as.

What was wrong. The service creates C:\ProgramData\Observer the first time it starts and keeps its machine token and certificate there. On Windows any standard user can create a folder under C:\ProgramData and own it. If someone did that first and put a credentials.json or a certificate.pfx inside, every published release up to 0.24.0 repaired the folder's ownership and permissions and then used the file it found: a token that is accepted from the network, and that can also end processes, or a certificate whose private key that person holds. Uninstalling removes the folder, so a reinstall reopens the same chance.

Are you affected? Only if someone else had a local account, or code you did not trust ran as a standard user, on the machine and could create that folder before the service first started. On a machine only you use, and where nothing untrusted has run as a standard user, no.

The folder itself no longer tells you: the old service rewrote its owner and permissions until it looked exactly like its own. The files inside do. The old service repaired the folder only, never the files in it, so a file that was planted keeps its planter as owner, while the service creates credentials.json and certificate.pfx as SYSTEM or Administrators. From an elevated terminal:

Get-ChildItem C:\ProgramData\Observer | ForEach-Object { '{0}  {1}' -f (Get-Acl $_.FullName).GetOwner([Security.Principal.SecurityIdentifier]).Value, $_.Name }

S-1-5-18 is SYSTEM and S-1-5-32-544 is Administrators (or the account the service runs as, if it is not LocalSystem). Any other owner on either file means that account put it there.

What to do

1. Upgrade: from an elevated terminal, msiexec /i Observer.msi with the package attached to this release. Your token and certificate are kept. Upgrading does not undo an earlier adoption: whoever planted the files still owns them and can rewrite them.
2. If either file is owned by another account, or you cannot tell: delete C:\ProgramData\Observer\certificate.pfx and C:\ProgramData\Observer\credentials.json, then run Restart-Service Observer. The service creates both again. Every machine that watches this one is cut off until it is given the new fingerprint and token; observer share prints both.

What to expect after upgrading. Usually nothing. The service now refuses to start when the folder is not empty and its owner or permissions are not SYSTEM and Administrators alone, and it changes nothing. That happens to a folder recreated by hand, restored from a backup without its permissions, or left by the service run by hand or under another account. The reason is in the Windows Application event log (source .NET Runtime), and the recovery, three icacls lines, is in the README under Packages. An empty folder that kept the permissions it inherited is replaced with a protected one and the service starts. On a machine in that state the installer may stop with error 1920 and go back to the previous version: fix the folder first, then run the installer again, because restarting the service would only restart the old one.

One weakness remains, and it is availability, not the token: someone who creates the folder and puts anything in it, or a file at that path, or who takes SYSTEM out of the permissions of an empty folder they own, can keep the service from starting until an administrator clears it.

The packages are NOT signed

Windows will say so twice, in two different ways, and the two are not fixed
by the same thing:

• User Account Control will show "Unknown publisher". A signature removes
  this immediately, from the first download;
• SmartScreen will warn on first run of the installer. A signature does
  NOT remove this: since March 2024 not even an EV certificate bypasses it.
  It depends on how many clean downloads the file has accumulated, not on the
  certificate it carries.

To go ahead: More info, then Run anyway.

Where this package comes from

Every attached file carries a provenance attestation signed by GitHub, which
ties it to the commit and the workflow that produced it:

gh attestation verify Observer.msi --repo Akr0n/observer

It is not an Authenticode signature and Windows does not look at it. It answers
a different and equally useful question: does this file really come from that
source code, rather than does Windows trust whoever made it.

Windows

Installs the service, the dashboard and the command line. Needs an elevated terminal:

msiexec /i Observer.msi

Nothing else needs installing: the package bundles the .NET runtime, which is
why it weighs about fifty megabytes. Up to 0.2.0 it required ASP.NET Core 10
without checking that it was there, and on a machine without it the service
died at startup while the installer talked about insufficient privileges - a
cause that had nothing to do with the real one.

Note that this means the runtime's security fixes no longer come from
Windows Update. They come with a new Observer release.

If that machine already has an Observer service registered by hand, remove it
first, and empty the installation folder.

Linux

sudo apt install ./observer_0.24.1_amd64.deb

Requires Ubuntu 24.04 or later: aspnetcore-runtime-10.0 comes from the official
archive, so the runtime is not bundled and is updated with the system.

After installing

To watch the machine you are sitting at there is nothing to configure, and no token
is needed: the dashboard uses the local channel. The token and the certificate
fingerprint are needed only so that ANOTHER computer can query this one, and you get
them with observer share.