screaming in digital

fixate on what you think you know… you’re missing what you don’t though.

  • 0 Posts
  • 45 Comments
Joined 4 years ago
Cake day: May 7th, 2023
  • screaming in digital@lemmy.mltoCybersecurity@sh.itjust.works•New ClamAV security patch closes seven scanner bugs dating back two decades - Help Net SecurityEnglish
    3·
    4 months ago

    a security site that (kinda) demands JS shields down? sigh… anyway here is the article for those that prefer to not do silly things…

    cw: OOB writes and race conditions.

    Open source antivirus scanning sits inside mail gateways, file upload checks, and endpoint tooling at organizations of every size. Much of that work runs through ClamAV, the scanning engine maintained by Cisco’s Talos group. The project released two patch versions, 1.5.3 and 1.4.5, carrying fixes for seven security flaws along with smaller hardening changes.

    Most of the patched bugs sit in the code that unpacks and parses executable formats, the part of a scanner built to handle hostile input. CVE-2026-20213 is an integer overflow in the PE rebuild size calculation that a malformed Aspack-packed file can trigger, leading to a heap buffer overflow write. The related CVE-2026-20214 covers an FSG unpacker loop underflow that can write past the section array during a scan of a crafted PE file. Both reach far back through the codebase, with the FSG issue present in builds dating to 2004.

    CVE-2026-20217 rounds out the PE group. A bug in the PESpin unpacker cleanup path could free pointers into the scanned file buffer and crash the scanner. That flaw has lived in the code since 2005. Archive and image format bugs

    Three more fixes address archive and disk-image handling. CVE-2026-20215 is a 7z parser substream count overflow that can under-allocate parser metadata arrays and then write past them when reading a crafted archive. CVE-2026-20243 covers ALZ parser size handling errors that can make malformed ALZ archives panic, abort the scanner, or skip expected scan-limit handling. CVE-2026-20216 is an InstallShield archive extraction limit bypass that can write far more temporary data than intended and drain temporary storage.

    The last parsing flaw, CVE-2026-20244, sits in the 32-bit DMG parser. A short mish stripe table could pass validation and crash the scanner. This one affects only 32-bit builds, going back to version 0.98.1, and leaves 64-bit builds untouched. Quarantine race condition

    The releases also harden the quarantine actions in clamscan, clamdscan, and clamonacc against time-of-check/time-of-use races. Under unsafe quarantine directory settings, those races could redirect files as the scanner copied, moved, or removed them. Hiroki Imai of Ricerca Security, Inc. reported the issue.

    Version 1.5.3 adds a few items beyond 1.4.5. It upgrades the Rust tar dependency to resolve two RUSTSEC advisories and moves the Rust openssl dependency past CVE-2026-41676. Metadata preclass scans now run before the final scan verdict. A ClamOnAcc fix addresses hash bucket list corruption when two watched paths land in the same bucket. Both releases raise the minimum CMake version to 3.17 to repair Linux builds that link static dependencies against libcurl v8.21.0.

    The release files are available on the GitHub release page, and through Docker Hub in Alpine and Debian containers.

  • screaming in digital@lemmy.mltoLinux@lemmy.ml•Does anyone choose Debian?English
    1·
    5 months ago

    ymmv, but debian has always been near perfect through upgrades for me: even a recent buster -> bullseye -> bookworm -> trixie went smoothly.

    issues usually arise from not maintaining a clean debian stable install (e.g. you were using backports or lots of 3rd party repos). if those are cleaned up prior things still usually go well.

    not saying you didn’t have issues, but in my experience with with lots and lots of debian systems, upgrades have been 99.9% cakewalk.

  • screaming in digital@lemmy.mltoSelfhosted@lemmy.world•Where to get third party UPS batteries?English
    2·
    5 months ago

    honestly, I have always had pretty decent experiences with non-oem lead-acid batteries. my local battery place has a decent supply and longevity is roughly the same as the oem ones (3-4 years). I have never had any issues (type or frequency) that were not also an issue with oem batteries.

    almost no UPS mfcr makes their own batteries, so if you strip off the labeling from the oem ones, you may even find an exact replacement.

    edit: another advantage of a local place is the core-return rebate and disposal of your old batteries.

  • screaming in digital@lemmy.mltoSelfhosted@lemmy.world•Need help figuring out how to write Let's Encrypt ACME servers into banIP allowlist (OpenWrt)English
    3·
    6 months ago

    agreed. you are using DNS-01 challenges. so the workflow is…

    your local certbot machine initiates an https connection to the letsencrypt servers to start the DNS-01 challenge. during this HTTPS dialog, your local certbot is informed of the key material to insert into your DNS records. your local certbot then modifies your netcup DNS server (hosted remotely, not on your local network) with the keying material and the letsencrypt servers verify that the keys are actually there, proving that you control the domain. the letsencrypt serves then issue you the certificate (again, via HTTPS) and your local certbot stores it in your local host.

    the issue is most likely stems from the initial HTTPS connection that certbot tries to make to the let’s encrypt servers. while your firewall allows this traffic out, it does not allow return traffic back in because of your explicit blocking of US (and perhaps other) based addresses.

    even through your are using DNS for your domain autentocation, your local host - the machine running certbot - is unable to initiate the certificate transfer because of the firewall blocking return traffic.

    the two external networks (and, therefore IP ranges/subnets/etc) that are important here are the let’s encrypt servers and the netcup DNS servers. certbot will have to talk to both of these in order to function.

  • screaming in digital@lemmy.mltoSelfhosted@lemmy.world•Need help figuring out how to write Let's Encrypt ACME servers into banIP allowlist (OpenWrt)English
    1·
    6 months ago

    not sure what you mean by external DNS

    not hosting your own DNS server. specifically it sounds like your DNS server is hosted on your domain provider, not your own local network. you have set up certbot to automatically configure your remotely hosted DNS server for the DNS based renewal.

    if DNS based recert was working before then it should be working now.

    as I said in my edit, you are likely blocking the return https traffic from the US based let’s encrypt acme servers - so your initial diagnostic is correct. your local firewall is likely stopping the acme servers from talking back to your local host.

    you are right back where you started, asking for info in how to allow-list the acme IP ranges. but at least we may now know why it is not working and you are seeing an https timeout even though you are using DNS based certificate renewals.

    edit: typos

  • screaming in digital@lemmy.mltoSelfhosted@lemmy.world•Need help figuring out how to write Let's Encrypt ACME servers into banIP allowlist (OpenWrt)English
    3·
    6 months ago

    The DNS server/root isn’t in my home network

    are you using external DNS hosting? is it in a (now) blocked country? if so, then your local certbot is unable to update the DNS server records (return traffic from your DNS host is being blocked by your iptables/nftables config).

    error: HTTPSConnectionPool(host=‘acme-v02.api.letsencrypt.org’, port=443): Read timed out. (read timeout=45)

    yeah, that would suggest an https renewal method. had you previously configured web server renewal at all before switching over to DNS? any other suspicious notifications in the logs?

    edit: in thinking about this a little more… the renewal has to be initiated by your host, and that is likely done via https (you talk https to the acme server and tell it you want a renewal by DNS). so, if you are blocking the acme servers then the same issue applies - no return traffic.