CIRCLE WITH A DOT

datacenter infrasonic noise?

ok

- YouTube

Auf YouTube findest du die angesagtesten Videos und Tracks. Außerdem kannst du eigene Inhalte hochladen und mit Freunden oder gleich der ganzen Welt teilen.

(www.youtube.com)

@da_667 the thing that really worries me about this stuff:

these phishing tests use weird domains, which spam systems have to pass through (otherwise your phishing test is blocked by your antiphishing system).

Now what happens if proofpoint (or whoever) forgets to renew the phishing-test-domain but also forgets to remove the phishing-test-domain from their 'always allow' list? And then some actual phishers register the domain and start using it for, I dunno, phishing?

Anyway I'll steal @Dio9sys 's line and say "Hi, I get paid to be paranoid and anxious"

@Dio9sys @neurovagrant I am 100% stealing this.

@neurovagrant "now verify the package by trusting github and 900 npm dependencies"

working in security it is fun that security lives rent-free in my head.

The thing I keep thinking about regarding Epstein is:

This wasn't just one dude (or a dude and a single helper) running a human trafficking gig. C'mon.

Who is the new 'CEO' (is the term 'Don' too on the nose? it is an organized crime thing after all) of this enterprise? Because you just know there is a new one...

@jakuje Oh interesting! I missed that this strlen() check was an intermediate fix.

After staring at ASN.1 parser code for a few minutes I guess:

If the asn.1 tag type 0xf3 has a very large length field

and if the url string itself contains the first slash quite early (e.g. 'http:///AAAAAAA....'

then fp can point to a long buffer, say 10,000 bytes

then integer underflow makes the call to sc_get_cache_dir() somewhat unsafe (depends what kind of control we can expect to have over the directory config/environment variables, possibly a buffer overflow inside this function though)

and yes then 'filename' buffer could then be overflowed

interesting bug then. this requires physical access? assuming that this asn.1 tag is only read off of a card itself? i am guessing crl or some other feature...

@dangoodin I wrote up an analysis of the first 'vulnerability' they wrote about. it does not appear to be a vulnerability at all (sure the original code uses 'unsafe' functions, but you can't exploit anything as far as I can tell). https://infosec.exchange/@reverseics/116067178548980458 .

I can't speak to the second vulnerability they wrote about, it would take me too long to determine whether it is a real or a hallucinated bug.

@rrdot i would have done “find ./ -type f | xargs grep -B5 strcat” and then been convinced it was not exploitable after a few minutes, sure.

but i am old and slow ;).

Anthropic wrote a blog post about their LLM finding 0days in open source projects. I reviewed the first vulnerability they reported, in OpenSC, and as far as I can tell the bug isn't even real? I think so anyway, otherwise I'll eat some humble pie.

I was looking at the code at the time (so a few weeks ago, before opensc removed the strcat call and replaced with strlcat):

OpenSC/src/libopensc/card-piv.c at 33ab343a5c7d80db8cbc17d26f0edbe9dcdae299 · OpenSC/OpenSC

Open source smart card tools and middleware. PKCS#11/MiniDriver/Tokend - OpenSC/src/libopensc/card-piv.c at 33ab343a5c7d80db8cbc17d26f0edbe9dcdae299 · OpenSC/OpenSC

GitHub (github.com)

The offending lines are around line 5145. According to anthropic, this is a buffer overflow found by their predictive text algorithm.

But it's interesting to read the code and to read the context of the code. 'fp' is a string guaranteed to be 64 bytes in length, because of line 5138. This checks the strlen(fp) and if it isn't 64, the code exits with an error.

So the math is: 'filename' is filled with a string that is at maximum 4096-64-2 bytes long == max 4030 bytes. This value (maximum 4030) is eventually passed to a strlcat() call inside of sc_get_cache_dir(), where it is used as the 'size' argument. This means that 'filename' has a maximum size of 4030 bytes when sc_get_cache_dir() exits.

Then the code strcat's one byte (for the '/'), onto the 'filename' buffer, then 64 more bytes (for the 'fp' string) onto 'filename' buffer, meaning the buffer cannot be overflowed because the maximum string length is now 4095 (the last byte being a null terminator).

So, anthropic's LLM probably spent 4 seconds 'finding' this 'vulnerability'. I spent about an hour looking at the code to debunk their finding (really 20 minutes looking at the code, followed by 40 minutes of hemming and hawing about whether I'm right and making sure there wasn't a signed size or some other gotcha, then being anxious about saying anything because golly human brains are funny machines).

I guess it's cool that opensc changed the calls to strlcat() now and that is probably a good thing, but this was never even a bug anyway so it didn't help anything today.

Unless the compiler magically omits instructions like the strlen() check some day. Which, if we really go down the path of compilers being generated by LLMs I guess that is a valid concern .

@watchTowr Ivanti keeping its top spot, for now...

@Viss we dont know who struck first, us or the machines…

The existence of Comic Sans implies that there is Comic Avec font somewhere.