Mastodawn

CVSS 8.8 vulns in ingress-nginx:

ingress-nginx: < v1.13.7
ingress-nginx: < v1.14.3

More info:
1) https://github.com/kubernetes/kubernetes/issues/136677
2) https://github.com/kubernetes/kubernetes/issues/136678
3) https://github.com/kubernetes/kubernetes/issues/136679
4) https://github.com/kubernetes/kubernetes/issues/136680

#devops #kubernetes #infosec

ReynardSec Jan 31

CERT Polska has published a report detailing a coordinated cyberattack against Poland’s energy sector, including renewable energy facilities and a large CHP plant.

https://cert.pl/uploads/docs/CERT_Polska_Energy_Sector_Incident_Report_2025.pdf

#infosec #cybersecurity #threatintelligence #nationalsecurity #europe #energy #cert

ReynardSec Oct 17

A grumpy ItSec guy walks through the office when he overhears an exchange of words.

devops0: I'll push the new image - just pull "latest"

ItSec (walking by): Careful. "latest" doesn't work the way you think.

devops1: How so?

ItSec: It's just a tag. Whoever pushes the image decides what "latest" points to. Sometimes it's the newest.

First, assume you have a local registry running on localhost:5000 and two Ubuntu images already present: ubuntu:23.04 and ubuntu:22.04. Tag and push both by their actual versions so the registry has explicit versioned tags. Then, on purpose, point latest to 22.04.

# start quick&dirty&unsecure local registry
docker run -d --name registry -p 5000:5000 --restart=always registry:2


# push explicit versions
docker tag ubuntu:23.04 localhost:5000/ubuntu:23.04
docker push localhost:5000/ubuntu:23.04

docker tag ubuntu:22.04 localhost:5000/ubuntu:22.04
docker push localhost:5000/ubuntu:22.04

# intentionally make "latest" refer to 22.04
docker tag ubuntu:22.04 localhost:5000/ubuntu:latest
docker push localhost:5000/ubuntu:latest

Now pull without a tag and see what you actually get. Omitting the tag defaults the client to requesting “:latest”. Because you explicitly set latest to 22.04, that’s exactly what will be pulled and run.

# pull without a tag -> defaults to :latest
docker pull localhost:5000/ubuntu

# verify the version by inspecting inside a container
docker run --rm localhost:5000/ubuntu cat /etc/os-release | grep VERSION=

VERSION="22.04.5 LTS (Jammy Jellyfish)"

If you now retag latest to 23.04 and push again, the same pull with no tag will start returning 23.04. Nothing "automatic" updated it; you changed it yourself by moving the tag.

That's the entire point, latest is a conventional, movable label, not a magical link to the newest software. It can be older than other tags in the same repository if someone set it that way. It can also be missing entirely.

For more grumpy stories visit:
1) https://infosec.exchange/@reynardsec/115093791930794699
2) https://infosec.exchange/@reynardsec/115048607028444198
3) https://infosec.exchange/@reynardsec/115014440095793678
4) https://infosec.exchange/@reynardsec/114912792051851956
5) https://infosec.exchange/@reynardsec/115133293060285123
6) https://infosec.exchange/@reynardsec/115178689445065785
7) https://infosec.exchange/@reynardsec/115253419819097049

#appsec #devops #programming #webdev #docker #containers #cybersecurity #infosec #cloud #sysadmin #sysops #java #php #javascript #node

ReynardSec Oct 2

There is a special circle of hell reserved for corporate intranets. Wikis, conflu and other graveyards… An endless labyrinth of outdated, half-written, barely-searchable pages. They exist only so that, at a convenient moment, the c-level can say: "there is a page on the wiki about this!". Burn it with fire.

ReynardSec Sep 23, 2025

A grumpy ItSec guy walks through the office when he overhears an exchange of words.

devops0: Two containers went rogue last night and starved the whole host.
devops1: What are we supposed to do?

ItSec (walking by): Set limits. It's not rocket science. Docker exposes cgroup controls for CPU, memory, I/O and PIDs. Use them.

The point is: availability is part of security too. Linux control groups allow you to cap, isolate and observe resource usage, which is exactly how Docker enforces container limits for CPU, memory, block I/O and process counts [1]. Let's make it tangible with a small lab. We'll spin a container, install stress-ng, and watch limits in action.

# On the Docker host
docker run -itd --name ubuntu-limits ubuntu:22.04
docker exec -it ubuntu-limits bash

# Inside the container
apt update && apt install -y stress-ng
stress-ng --version

Check how many cores you see, then drive them.

# Inside the container
nproc

# For my host nproc returns 4
stress-ng --cpu 4 --cpu-load 100 --timeout 30s

In another terminal, watch usage from the host.

docker stats

Now clamp CPU for the running container and see the throttle take effect.

docker update ubuntu-limits --cpus=1
docker stats

The --cpus flag is a wrapper over the Linux CFS period/quota; --cpus=1 caps the container at roughly one core worth of time on a multi‑core host.

Memory limits are similar. First tighten RAM and swap, then try to over‑allocate in the container.

# On the host
docker update ubuntu-limits --memory=128m --memory-swap=256m
docker stats

# Inside the container: stays under the cap
stress-ng --vm 1 --vm-bytes 100M --timeout 30s --vm-keep

# Inside the container: tries to exceed; you may see reclaim/pressure instead of success
stress-ng --vm 1 --vm-bytes 300M --timeout 30s --vm-keep

A few memory details matter. --memory is the hard ceiling; --memory-swap controls total RAM+swap available. Setting swap equal to memory disables swap for that container; leaving it unset often allows swap equal to the memory limit; setting -1 allows unlimited swap up to what the host provides.

docker run -it --rm \
  --name demo \
  --cpus=1 \
  --memory=256m \
  --memory-swap=256m \
  --pids-limit=25 \
  ubuntu:22.04 bash

For plain docker compose (non‑Swarm), set service‑level attributes. The Compose Services reference explicitly supports cpus, mem_limit, memswap_limit and pids_limit on services [2].

services:
  api:
    image: ubuntu:22.04
    command: ["sleep","infinity"]
    cpus: "1"              # 50% of one CPU equivalent
    mem_limit: "256m"      # hard RAM limit
    memswap_limit: "256m"  # RAM+swap; equal to mem_limit disables swap
    pids_limit: 50         # max processes inside the container

[1] https://docs.docker.com/engine/containers/resource_constraints/
[2] https://docs.docker.com/reference/compose-file/services/

#appsec #devops #programming #webdev #docker #containers #cybersecurity #infosec #cloud #sysadmin #sysops #java #php #javascript #node

ReynardSec Sep 17, 2025

"One Token to rule them all - obtaining Global Admin in every Entra ID tenant via Actor tokens"

https://dirkjanm.io/obtaining-global-admin-in-every-entra-id-tenant-with-actor-tokens/

#entra #azure #cloud #devops #infosec #cybersecurity #pentesting #pentest

ReynardSec Sep 16, 2025

my 16e with #ios26

#apple

ReynardSec Sep 16, 2025

Not sure who is using "Kubernetes C# Client" but:

"A vulnerability exists in the Kubernetes C# client where the certificate validation logic accepts properly constructed certificates from any Certificate Authority (CA) without properly verifying the trust chain"

CVSS Score: 6.8

More details: https://groups.google.com/g/kubernetes-security-announce/c/rLopt2Msvbw/m/rK6XeNw2CgAJ

#kubernetes #devops #sysadmin #k8s #windows

ReynardSec Sep 16, 2025

"Abusing an 0day to steal the data that fuels macOS AI"

"In a nutshell, plugins can only access files when the Spotlight subsystem requests it and, in theory, should only return extracted information back to Spotlight—nobody else! But is Apple’s sandboxing sufficient? 🤔

Today, we’ll present a 0-day that leverages a bug from almost a decade ago(!) — one that can still be exploited from a Spotlight plugin, even on macOS Tahoe, to access TCC-protected files, including sensitive databases that log user and system behaviors that can power Apple’s AI features 😈"

https://objective-see.org/blog/blog_0x81.html

#macos #apple #macos26 #cybersecurity #infosec

ReynardSec Sep 10, 2025

devops0: Our audit report says we must "enable Docker rootless mode". I have no clue what that even is...
devops1: Sounds like some another security BS. What's "rootless" supposed to do?

ItSec: Relax. Rootless mode runs the Docker daemon and containers as a regular, unprivileged user [1]. It uses a user namespace, so both the daemon and your containers live in "user space", not as root. That shrinks the blast radius if the daemon or a app in container is compromised, because a breakout wouldn't hand out root on the host.

devops1: Fine. If it's "not hard" to implement, we can consider this.

ItSec: Deal.

Note: this mode does have some limitations. You can review them in docs [2].

First, let's check which user the Docker daemon is currently running as.

ps -C dockerd -o pid,user,group,cmd --no-headers

You should see something like:

9250 root     root     /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock

Here's a clean, minimal path that matches the current docs. First, stop the rootful daemon.

sudo systemctl disable --now docker.service docker.socket

Then install the uid/gid mapping tools. On Ubuntu it's uidmap.

sudo apt update && sudo apt install -y uidmap

Docker provides a setup tool. If you installed official DEB/RPM packages, it's already in /usr/bin. Run it as your normal user.

dockerd-rootless-setuptool.sh install

If that command doesn't exist, install the extras package or use the official rootless script.

sudo apt-get install -y docker-ce-rootless-extras
# or, without package manager access:
curl -fsSL https://get.docker.com/rootless | sh

The tool creates a per-user systemd service, a "rootless" CLI context, and prints environment hints. You usually want your client to talk to the user-scoped socket permanently, so export DOCKER_HOST and persist it in your shell profile.

export DOCKER_HOST=unix:///run/user/$(id -u)/docker.sock
echo 'export DOCKER_HOST=unix:///run/user/$(id -u)/docker.sock' >> ~/.bashrc

Enable auto-start for your user session and let services run even after logout ("linger").

systemctl --user enable docker
sudo loginctl enable-linger $(whoami)

Point the CLI at the new context and sanity-check.

docker context use rootless

Once more, check which privileges the Docker daemon is running with:

ps -C dockerd -o pid,user,group,cmd --no-headers

Now you will see something like:

10728 ubuntu   ubuntu   dockerd

And pssst! Podman runs containers in "rootless" mode by default [3].

[1] https://docs.docker.com/engine/security/rootless/
[2] https://docs.docker.com/engine/security/rootless/troubleshoot/
[3] https://documentation.suse.com/en-us/smart/container/html/rootless-podman/index.html#rootless-podman-sle

#appsec #devops #programming #webdev #java #javascript #python #php #docker #containers #k8s #cybersecurity #infosec #cloud #hacking #sysadmin #sysops

Website	https://reynardsec.com/en/
Blog	https://reynardsec.com/en/blog/
E-mail	[email protected]