Look at this person over here using branches, show off

For loops with find are evil for a lot of reasons, one of which is spaces:

$ tree
.
├── arent good with find loops
│   ├── a
│   └── innerdira
│       └── docker-compose.yml
└── dirs with spaces
    ├── b
    └── innerdirb
        └── docker-compose.yml

3 directories, 2 files
$ for y in $(find .); do echo $y; done
.
./are
t good with fi
d loops
./are
t good with fi
d loops/i

erdira
./are
t good with fi
d loops/i

erdira/docker-compose.yml
./are
t good with fi
d loops/a
./dirs with spaces
./dirs with spaces/i

erdirb
./dirs with spaces/i

erdirb/docker-compose.yml
./dirs with spaces/b

You can kinda fix that with IFS (this breaks if newlines are in the filename which would probably only happen in a malicious context):

$ OIFS=$IFS
$ IFS=$'\n'
$ for y in $(find .); do echo "$y"; done
.
./arent good with find loops
./arent good with find loops/innerdira
./arent good with find loops/innerdira/docker-compose.yml
./arent good with find loops/a
./dirs with spaces
./dirs with spaces/innerdirb
./dirs with spaces/innerdirb/docker-compose.yml
./dirs with spaces/b
$ IFS=$OIFS

But you can also use something like:

find . -name 'docker-compose.yml' -printf '%h\0' | while read -r -d $'\0' dir; do
      ....
done

or in your case this could all be done from find alone:

find . -name 'docker-compose.yml' -execdir ...

-execdir in this case is basically replacing your cd $(dirname $y), which is also brittle when it comes to spaces and should be quoted: cd "$(dirname "$y")".

Not exactly “memory address 0”; there be dragons there. https://c-faq.com/null/index.html

@ matches

Yes social engineering can be incredibly effective. I completely agree, but there is a bit of an obsession with it these days and imo it’s over indexed, because at the end of the day the type of social engineering detailed in that report typically just provides access.

In some cases, the target is important enough and has enough organizational power that accessing the network as them is sufficient, but that’s not often the case. What that means is that in those other cases social engineering (which in that report you cited is often just phishing) is providing, typically, internal network access. An attacker will have to move through the network and exploit software typically to continue their attack. There are many points in this chain that the weakness lies in software or configuration. If effort was placed on making those systems better it would likely see better results than hyper focusing on the social engineering, which is significantly more difficult to stop, especially with all of the things you mentioned on the horizon.

My point is then that even if it is a part of 74% of breaches, according to Verizon, it’s not necessarily sufficient and is often paired with software level exploits.

And I know this because my company does plenty of red teaming, and we use social engineering but at the end of the day the more interesting result comes from a software exploit or just abusing a weak configuration.

I have found the exact same type of bug shown here probably over a dozen times, most of those long before AI was writing code.

Not a big fan of the wording here. Plenty of skilled programmers make dumb mistakes. There should always be systems in place to ensure these dumb mistakes don’t make it to production. Especially when related to sensitive information. Where was the threat model and the system in place to enforce it? The idea that these problems are caused by “shit programmers” misses the real issue: there was either no system or an insufficient system to test features and define security requirements.

I work in security and I kinda doubt this. There are plenty of issues just like what is outlined here that would be much easier to exploit than social engineering. Social engineering costs a lot more than GET /secrets.json.

There is good reason to be concerned about both, but 95% sounds way off and makes it sound like companies should allocate significantly more time to defend against social engineering, when they should first try to ensure social engineering is the easiest way to exploit their system. I can tell you from about a decade of experience that it typically isn’t.

I don’t want to tell you one way or the other because it’s kinda dubious anyway, but if all services run as the same user the need for root is kinda moot when it comes to crossing between services or expanding the scope of an attack. Of course it is better than all things running as root, but if I popped a machine as some “low privilege” user that still had access to all running services I’m not sure I’d care so much about escalating to root.

Woah, no. Sure escaping via a kernel bug or some issue in the container runtime is unexpected, but I “escape” containers all the time in my job because of configuration issues, poorly considered bind mounts, or the “contained” service itself ends up being designed to manage some things outside of the container.

Might be valid to not consider it with the services you run, but that reasoning is very wrong.

LXC is containerization. Both it and Docker are using the same kernel APIs.

Agreed

Not really, but I’d probably try to organize those into sub structures where it made sense. A data structure holding the UI state and FFT data all flat is kinda messy imo since it becomes unclear what is actually required where.

I have no skin in this game, but IPs are definitely not anonymous data. Also there is a lot of great info out there about de-anonymizing seemingly random data. Interestingly enough, this is similar to the Netflix prize dataset that was one of the more famous ones. Maybe a good introduction to that would be https://www.schneier.com/blog/archives/2007/12/anonymity_and_t_2.html

Nobody is gonna be using a quantum computer to “crack email hashes” of Plex users in a few years… I’m not even sure there is a speedup to hash cracking with quantum computers.

But depending on the hashing algorithm used, it’s likely pretty easy to crack hashes of email addresses today with a normal computer. They’re not particularly high entropy.

QEMU makes it pretty painless to hook up gdb just FYI; you should look into that. I think you can also have it provide a memory mapped UART for I/O which you can use with newlib to get printf debugging

I feel seen

Pretty much everyone I work with uses vim, emacs, sublime, or vscode. I like IDEs and use them for… well Java, but I wouldn’t argue that they’ve made the other tools obsolete or you’re a fool for sticking with the old ones. If it ain’t broke and all that. It actually seems like more people are moving back to pluggable text editors over IDEs

I’ve used AI tools a bit. They’ve really helped drop in code that would previously just be a bunch of TODOs; they get you up and writing the core parts much faster to see if the idea even works. They’ve also really helped answer specific questions or lead me towards the answer. They’ve also straight up lied to me quite a bit. It’s a weird tool.

I think the OP image is pretty wrong with the comparison it makes. LLMs/AI are a class of technology that are most definitely not going anywhere unless something dramatic happens. Some people, myself included, feel uneasy about the way they’re created and the fact that people in powerful positions completely misunderstand them, and I think that leads to the hope that they’re just a fad.

Could be a variable from somewhere else in the code. It should throw type error of some sort if it’s not going to handle a float correctly

TIL I didn’t realize Java used UTF16 for its internal representation. Looks like it’s a bit more complicated than that after Java 9 too