I’m the administrator of kbin.life, a general purpose/tech orientated kbin instance.

  • 0 Posts
  • 62 Comments
Joined 3 years ago
cake
Cake day: June 29th, 2023

help-circle
  • However, my understanding is that this could be exploited only by authenticated users with permission to add new media. Not like that’s a risk to ignore, but it’s not like it could be exploited by anyone on the Internet.

    I wonder if that’s the reason for setting the default live TV management permission to false. Since that permission might well the the route to adding your own malicious m3u link for that second change.


  • Reverse proxy will let anyone connect to it. VPN, you can create keys/logins for your intended users only. Having said that, from what I could see, nothing in the security fixes were to do with authentication. I think (just from a cursory look), they could only be exploited, if at all from an authenticated user session.

    But personally, something like jellyfin where the number of people I want to be able to access it is very limited, stays behind a VPN. Better to limit your potential attack surface as much as you can.


  • From a cursory look at just the security commits. Looks like the following:

    • GHSA-j2hf-x4q5-47j3: Checks if a media shortcut is empty, and checks if it is remote and stores the remote protocol if so. Also prevent strm files (these are meant to contain links to a stream) from referencing local files. Indeed this might have been used to reference files jellyfin couldn’t usually see?
    • GHSA-8fw7-f233-ffr8: Seems to be similar, except for M3U file link validation and limiting allowed protocols. It also changes the default permissions for live TV management to false.
    • GHSA-v2jv-54xj-h76w: When creating a structure there should be a limit of 200 characters for a string which was not enforced.
    • GHSA-jh22-fw8w-2v9x: Not really completely sure here. They change regex to regexstr in a lot of places and it looks like some extra validation around choosing transcoding settings.

    I’m not really sure how serious any of these are, or how they could be exploited however. Well aside from the local file in stream files one.







  • Oh, I forgot about Azerothcore (which is a fork from Trinitycore, and absorbed some changes from certain private server source that has been released in the past).

    Which you choose I think depends on what you want.

    Trinitycore has a more strict development policy of doing things properly and not for example concentrating too much on getting boss fights etc “right”. It’s more of a technical project than “ready to go private server”.

    Whereas (and this is as I understand it, I’ve not done any work for the project directly) Azerothcore is a bit more lax in their requirements. Now, don’t take this to mean they accept bad code. It just means they don’t have the stricter guidelines that trinitycore have.

    I could be wrong though. I’ve been out of the game for a while now.


  • I think so. I would consider perhaps allowing a short time without power before doing that. To handle short cuts and brownouts.

    So perhaps poll once per minute, if no power for more than 5 polls trigger a shutdown. Make sure you can provide power for at least twice as long as the grace period. You could be a bit more flash and measure the battery voltage and if it drops below a certain threshold send a more urgent shutdown on another gpio. But really if the batteries are good for 20mins+ then it should be quite safe to do it on a timer.

    The logic could be a bit more nuanced, to handle multiple short power cuts in succession to shorten the grace period (since the batteries could be drained somewhat). But this is all icing on the cake I would say.



  • My understanding is that the only issues were the write hole on power loss for raid 5/6 and rebuild failures due to un-seen damage to surviving drives.

    Issues with single drive rebuild failures should be largely mitigated by regular drive surface checks and scrubbing if the filesystem supports it. This should ensure that any single drive errors that might have been masked by raid are removed and all drives contain the correct data.

    The write hole itself could be entirely mitigated since the OP is building their own system. What I mean by that is that they could include a “mini UPS” to keep 12v/5v up long enough to shut down gracefully in a power loss scenario (use a GPIO for “power good” signal). Now, back in the day we had raid controllers with battery backup to hold the cache memory contents and flush it to disk on regaining power. But, those became super rare quite some time ago now. Also, hardware raid was always a problem with getting a compatible replacement if the actual controller died.

    Is there another issue with raid 5/6 that I’m not aware of?





  • Actually how is your ISP giving out IPs to you? Mine uses IPv6 PD to give me a /48. And I then use SLAAC locally on the first /64 prefix on my LAN. Plus another /64 for VPN connections.

    If you mean receiving RA/ND packets from your ISP (which are used to announce IPv6 prefixes) then you need to allow icmpv6 packets (if you don’t want to be able to be pinged, just block echo requests, ICMP in v4 and v6 carry important messages otherwise).

    If your ISP uses DHCPv6 Prefix delegation you will need to allow packets to UDP port 546 and run a DHCPv6 client capable of handling PD messages.

    If you have a fixed prefix, then you probably don’t need to use your ISPs SLAAC at all. You could just put your router on a fixed IP as <yourprefix>::1 and then have your router create RA/ND packets (radvd package in linux, not sure what it would be on pfsense) and assign IPs within your network that way.

    If you have a dynamic prefix… It’s a problem I guess. But probably someone has done it and a google search will turn up how they handled it.

    EDIT: Just clarified that the RA/ND packets advertise prefixes, not assign addresses.


  • I believe the privacy concerns are made moot if all consumer level routers by default blocked incoming untracked connections and you need to poke holes in the firewall for the ports you need.

    Having said that, even knowing the prefix it’s a huge address space to port scan through. So it’s pretty secure too with privacy extensions enabled.

    But for sure the onus is on the router makers for now.