Egress rules for Vero V

hdmicec_enjoyer · 26 May 2025 08:28

Hi

I was going to post this in the wiki topic, but I can’t do that, so posting here instead.

I use fine grained outbound traffic rules for every device on my network. I thought it may be of interest and useful to document outbound connections required by OSMC on my Vero V. This would be nice to have in the wiki. This will evolve and change as I fine tune my ruleset.

Please submit corrections or suggestions, it is inevitable that there will be mistakes by nature of this being a highly manual process. I will add DNS whitelists here also at some point, but I haven’t implemented this yet on my Vero V VLAN in my network.

FQDNs have been posted using [.] in place of . due to forum limitations on new accounts.

PROTOCOL | PORT | FQDN | PURPOSE

sam_nazarko · 27 May 2025 00:06

I wouldn’t use per-domain filtering.

Mirrors come and go. Not frequently, but we do load balance them and you may have not met a mirror that has been used yet (OSMC or Kodi side).

Egress you just need NTP; HTTP; HTTPS and DNS.

So 123 UDP
80 and 443 TCP
53 UDP

Smurphy · 27 May 2025 07:30

I agree with you @sam_nazarko , but I tend to also block lots of egress for the Fire-TV my family uses, and lots of other hosts/IP’s Microsoft, Meta and Apple use. So my egress list is quite long too.
I however tend to do that using a RPZ (DNS block list), and force all devices to use my DNS recursor and block DNS egress if not from the DNS Server.
The one part I am still unable to block is DoH if forced by the application.

It is sad that we have to go to such measures because the advertising and AI industry can never get enough

Kontrarian · 28 May 2025 07:59

It’s the surveillance economy (surveillance capitalism).
Avoid buying “smart” devices as much as possible, harden everything you can, and subscriptions are your enemy.
Oh, and remember that pretty much all “opt out” options are placebo buttons.
That’s about all you can do.

sam_nazarko · 28 May 2025 08:17

Interesting. I thought such rules would be to detect (early) and prevent compromise from say, a third party-addon but didn’t consider your motivation.

We are not in the washing machine business yet…

Why you need a washing machine connected to WiFi is beyond me… but anyway.

hdmicec_enjoyer · 28 May 2025 09:08

I prefer to do highly fine grained filtering to restrict potential for data exfiltration in the event of a compromise. It’s unfortunate that there are no “fixed place” mirrors usable (e.g. on RHEL you have only the RHEL CDN usable, or on Arch Linux I configure my workstations to only use the pkgbuild update servers which are run by Arch Linux), but I check my firewall logs daily since I run my home network like I run the enterprise networks I look after, so it’s a cost of doing business (at home :P).

This exercise has so far proven to be quite interesting. It would be nice to have a planned goal to move fully to using AEAD TLS traffic only. Moving from NTP to using NTS or HTTPS based time sync would be nice. And it would be quite nice to have all mirror/download communications fully using TLS. It’s unfortunate that plaintext HTTP is so prevalent.

It’s interesting how much potential a compromised networked HDMI device has actually. HDMI CEC is a very fun vector for exploitation, as almost every device has an old/buggy/insecure (denote as appropriate) HDMI CEC implementation, which could in theory allow for lateral movement between your Vero V to your TV, and then you could potentially leverage microphones in the TV remote in a worst case loss of confidentiality/integrity as part of a wider exploit chain to covertly snoop on people. Though, I doubt 99.999% of people here are in the scope of what would likely be a major state sponsored adversary with the desire and capability to do this But nonetheless it’s a fun thought exercise.

Another motivation for me doing this, is that the Vero V is quite outdated in terms of it’s OS/firmware. Debian bullseye (oldstable) isn’t really receiving the same level of TLC as stable Debian, and it isn’t actually the core Debian release/security teams dealing with issues and much of the packages. I want to reduce the risk as much as possible here. It would be nice also to update rtl8822cs firmware since it seems quite old and it wouldn’t shock me if there was proximal attack surfaces exposed there for example (speculation on my part!), I would be curious to know if the board support package from AMLogic for the S905X4 has got any extra updates also which could be deployed also. The kernel version being on 4.9.X is also something I would like to see shifted personally, since that will be missing many many upstream security patches from kernel.org.

Issues such as the former need to dealt with, since as part of the Product Security and Telecommunications Infrastructure Act in the UK (which is not being enforced - yet, it will be quite soon) the Vero V would likely fall under it and thus it needs to get proper patch coverage and have a clear end of life date (it can be a minimum end of support date) provided to end users.

sam_nazarko · 28 May 2025 09:22

Hi,

Appreciate the discussion.

What do you suggest?
I was considering ditching ntp for systemd-timesyncd in the near future.

We use an HTTPS call to get a lock on time from a remote server where: 1) NTP is blocked (it is surprisingly not uncommon); 2) the drift is so far out that NTP has problems (could be resolved now).

You could but this is very high effort and I am sure there would be better ways to get to you if someone wanted to.

The Vero V is moving to 5.15 (kernel) and Debian Trixie (which is now in hard freeze).

Updates are served over HTTPS.
They didn’t used to be, but that wasn’t a major issue because the Debian packages are signed. There are arguments that one could see over HTTP the user agent, know the target platform and system etc. But if you are resolving against apt.osmc.tv there’s probably a good assumption already…

More than aware of that and it won’t be a problem at all.
We have always given a minimum guarantee of updates, but never a specific EOL as we always exceed. For example we promised 5 years on the launch of Vero 4K (2017) but supported it until 2025.

We do backport any needed security fixes aggressively and the 4.9 kernel version you see isn’t 4.9 per se, just as the same way the RHEL kernel version that you see is definitely not the version you think it is (ABI and kernel structures may be intact, but it is a very different animal).

8822CS is up to date from Realtek and looks good. There isn’t really any BSP infrastructure from AML to update. OpTEE looks good and as DRM is mainly AML’s bread and butter, it is well looked after.

Cheers

Sam

Smurphy · 28 May 2025 09:54

The essence here is to prevent companies like Amazon, meta to evesdrop into your living room conversations
Do you have an Alexa connected device, or Echo device in your living room and had a discussion about a specific topic?
Chances are the next time the owner of the device connects to Amazon or instagram or whatever, he receives commercials on stuff for exactly that discussed topic.
That is the frightening part. It is not about detecting security issues anymore. It is about maintaining my private life away from these top players who do really not care about our privacy anymore.
This is the reason I have absolutely no “smart” devices at home. The 43" screen is a horrendly expensive Computer screen, it has the Vero 4 or 5 connected (depends on the location).
The Fire-TV Stick is running through my harmony remote and the batteries for the Alexa remote are removed. And the worst part is, if I block most of the Amazon advertising remote endpoints, it gets an absolute nightmare to just load Prime TV (which we stopped watching due to the overhelming and stupid commercial abuse), we just use it to load Netflix - but that one is having less and less decent content too so we’ll probably dump it soon too so I can dump the Firetv alltogether.
Oh - and BTW - the phones we have at home all come with IodéOS and I make sure that stays like that

hdmicec_enjoyer · 28 May 2025 09:55

What do you suggest?
I was considering ditching ntp for systemd-timesyncd in the near future.
We use an HTTPS call to get a lock on time from a remote server where: 1) NTP is blocked (it is surprisingly not uncommon); 2) the drift is so far out that NTP has problems (could be resolved now).

Honestly, why even bother with NTP/NTS if you have HTTPS based time sync based on the date field? It would be much less attack surface to do that and it will work everywhere pretty much.

ntpd-rs would be nice as it implements NTS support, so you can have proper encrypted+authenticated NTP. For fallback, I would personally implement HTTPS based time sync using the date field in the response headers. It would be nice to move the script in /usr/bin/http-time to using HTTPS instead of HTTP. Users can always set the time manually as a one time action in the event they setup the device on a network where NTP/NTS is blocked, or if that were to happen in future, and the fallback doesn’t kick in.

You could but this is very high effort and I am sure there would be better ways to get to you if someone wanted to.

Yeah of course - it’s basically near zero chance anyone is actually going to do that in the real world unless you are being targeted by a highly capable SIGINT adversary.

The Vero V is moving to 5.15 (kernel) and Debian Trixie (which is now in hard freeze).

Awesome

Updates are served over HTTPS.
They didn’t used to be, but that wasn’t a major issue because the Debian packages are signed. There are arguments that one could see over HTTP the user agent, know the target platform and system etc. But if you are resolving against apt.osmc.tv there’s probably a good assumption already…

I wonder what that plaintext traffic to mirrorservice.org is from then? I’ll have to try identify what that is exactly (Maybe Kodi addons?). HTTP based updates are still problematic since the attack surface posed by apt is quite high and there have been multiple issues in the past where adversaries on the wire were able to exploit systems due to this. See CVE-2016-1252 and CVE-2019-3462 as an example.

More than aware of that and it won’t be a problem at all.
We have always given a minimum guarantee of updates, but never a specific EOL as we always exceed. For example we promised 5 years on the launch of Vero 4K (2017) but supported it until 2025.

Awesome Glad to hear, the last thing I would want is to see OSMC harmed by it.

We do backport any needed security fixes aggressively and the 4.9 kernel version you see isn’t 4.9 per se, just as the same way the RHEL kernel version that you see is definitely not the version you think it is (ABI and kernel structures may be intact, but it is a very different animal).

It’s still quite problematic since much of the security issues in the kernel don’t get a CVE or aren’t even reported as a CVE etc. RHEL has the same issues as do many distribution kernels. Google setup Android GKI with gregkh to pretty much deal with this by having a stable ABI and pulling in security fixes missed by kernel.org and a lot of vendor specific code into 1 generic Linux tree. It would be nice to see something like that upstream but I doubt that’s ever going to happen… Glad to hear things will move to 5.15.

8822CS is up to date from Realtek and looks good. There isn’t really any BSP infrastructure from AML to update. OpTEE looks good and as DRM is mainly AML’s bread and butter, it is well looked after.

I come from a Qualcomm BSP land where there are updates nearly every month for much of the entire board’s firmware/drivers/userspace/etc, so that’s pretty peculiar to me. AMLogic don’t have as nice a TEE IMHO compared to QSEE in terms of defence in depth etc, but it’s not like it’s used for anything other than DRM currently in the Vero V (AFAIK - please correct if I’m wrong there), so it’s not really a big deal and the only real thing to care about on that front IMHO would be ensuring any kernel drivers for it are kept happy to mitigate any EoP issues etc. That said, it would be nice to take advantage of the flash controller’s capability to encrypt the eMMC flash. It would provide a proper secure factory reset experience much like on Android or iOS devices.

Thanks for the reply!

sam_nazarko · 28 May 2025 09:58

No.

And I make sure that no family members use Siri.

I’m not on Instagram either and prefer to live a very private life.
Unless I am desperately anticipating a call or travelling, you won’t find a phone on me either.

Completely understand and respect the privacy angle.

sam_nazarko · 28 May 2025 10:12

Because NTP handles drift… Our HTTP time service is very basic and does a one time lock:

github.com

osmc/osmc/blob/master/package/network-osmc/files/usr/bin/http-time

#!/bin/bash

# (c) 2014-2015 Sam Nazarko
# email@samnazarko.co.uk

# Set system time during boot using as a backup for ntpd when port 123 is blocked.

count=60
while [ $count -gt 0 ]; do
	if grep -q nfsroot /proc/cmdline; then
		ping -c 1 -W 2 time.osmc.tv >/dev/null 2>&1 && break
	else
		if connmanctl state | grep -iq 'online'; then break; fi
	fi
	sleep 5; let count-=5
done
if [ $count -lt 1 ]; then echo "No internet connectivity was detected within 60 seconds. Will try to send time query anyway."; fi

OLD_DATE=$(date -u)
for server in time.osmc.tv; do

This file has been truncated. show original

We indeed sync over HTTP and not HTTPS.
That script was written about a decade ago, but from my memory I chose HTTP instead of HTTPS because I figured how can you trust HTTPS if you don’t know the time?

Do find it. Might be something via OSMC ‘App Store’ but ideally that should be using HTTPS now.
APT updates are served over HTTPS for a long time now.

It won’t happen upstream, but we are indeed moving to Android 5.15 based GKI kernels for this exact reason. It’s a bit of a pain as everything becomes modularised but that is the way things are going and in some ways things are a lot easier to maintain.

Not familiar with Qualcomm but AML side covers things well: RPMB; anti-rollback etc.

This is already the case since Vero V.

Kernel and bootloader are signed and encrypted by us against a key burned in on eFuse on device. This key is flashed at shipping time locally in the UK. We also utilise RPMB on eMMC for other keys and it’s tied to the SoC.

Vero V was a big step up in terms of security in comparison to its predecessors; we just didn’t document it that much.

hdmicec_enjoyer · 28 May 2025 10:26

Because NTP handles drift… Our HTTP time service is very basic and does a one time lock:
We indeed sync over HTTP and not HTTPS.
That script was written about a decade ago, but from my memory I chose HTTP instead of HTTPS because I figured how can you trust HTTPS if you don’t know the time?

You might find some inspiration in what GrapheneOS did in their HTTPS based time sync. They only use HTTPS and it handles things pretty well. It has awareness of build time which deals with potential time sync issues. use HTTPS X-Time header for time updates instead of NTP · GrapheneOS/platform_frameworks_base@48bf19d · GitHub

Do find it. Might be something via OSMC ‘App Store’ but ideally that should be using HTTPS now.
APT updates are served over HTTPS for a long time now.

Will try!

we are indeed moving to Android 5.15 based GKI kernels for this exact reason.

Oh that’s awesome to hear. Yeah the GKI kernels are very nice to work with, and their modularity is very much appreciated over on my side as it makes it very much frictionless to do kernel updates due to the stable ABI. Though I suggest very extensively testing updates, as now and then there are some really annoying regressions, I used to keep an eye on https://android-review.googlesource.com/q/project:kernel/common+status:open as I found it was helpful to get information early on such matters.

Not familiar with Qualcomm but AML side covers things well: RPMB; anti-rollback etc.

Yeah it’s pretty standard stuff now, it’s mostly implementation quality, exploit mitigations and so on which are the notable items.

Kernel and bootloader are signed and encrypted by us against a key burned in on eFuse on device. This key is flashed at shipping time locally in the UK. We also utilise RPMB on eMMC for other keys and it’s tied to the SoC.

Awesome! Yeah I saw the signed u-boot images you were shipping out, that was nice to see . That would be really nice to see documented but I guess it’s a pretty niche thing for the average person who just wants to watch media on it lol.

Kontrarian · 30 May 2025 00:12

Oi mate! Ya got a loicense fer dat?

sam_nazarko · 30 May 2025 01:57

We’ve had a license for a while. A license to kill. You’ll die another day.

Sadly given 2025, your meme point is somewhat valid to the point where I have to say that this is truly satire and we have no intention of killing you.

Yet