We considered this just good discipline. I am sure that IT would have loved to allow just the mirror to have internet access, but it was an active decision not to let it, because it had potential to exfiltrate data out of the development network.

Reading this telling of the story, I can’t help but walk away with the conclusion that these frontier labs lack rigour when it comes to securing their models, especially given how much they hype up their models’ capabilities.

Utterly bizarre.

Somewhat tangential though, but I find the amount of perl clutching from the AI industry about writing malware code a bit ridiculous. Most of the examples cited in the article are just a Google search away. I do not think that the LLM generating malware for you lowers the bar one bit.

Comments URL: https://news.ycombinator.com/item?id=47150199

Points: 1

# Comments: 1

One thing which really helped me (and I wholeheartedly recommend) is to write simple programs, run them through the compiler and then in the disassembler. It really helps build a correspondence between program structure and its object code.

Eventually, you can make it even more fun and challenging by stripping debug symbols and turning on compiler optimisations.

Happy reversing!

Pardon my French, but this is the dumbest thing I have read all week. You simply cannot work on defensive techniques without understanding offensive techniques - plainly put, good luck developing exploit mitigations without having ever written or understood an exploit yourself. That’s how you get a slew of mitigations and security strategy that have questionable, if not negative value.

It’s possible to reverse engineer the OS code to verify that the biometrics indeed end up on the SEP’s encrypted storage, and several people have done this in the past.

Here’s an excellent presentation on the SEP, found by just a simple Google search. [0]

[0]: https://www.blackhat.com/docs/us-16/materials/us-16-Mandt-De...

The current title is a bit misleading, because several parts of macOS, including those covered partially by the OSS releases, are proprietary.

https://blog.umangis.me/static/08539708.pdf

Comments URL: https://news.ycombinator.com/item?id=33191171

Points: 6

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=32435601

Points: 63

# Comments: 15

As you put it, it really is a desire for maximum security at play here.

The author(s) maintain the site out of personal interest.

> __padding 45 minutes ago [dead] [–]

> Typically with devices like network cards (that also operate over PCI-E) You send the device a circular list of descriptors (pointers) to a region of main memory. In order to send data to the device, you write your network packet to the memory region associated with the pointer of the current ‘head’ of the descriptor list. So far, you have a ring of pointers, one of those pointers points to a location you just wrote to in ram. You then tell the device that the head of the list has changed (as you just wrote some data to the region that the head of the list is pointing to - so it can consume that pointer), the device then goes ahead and copies the data from ram into an internal buffer on the card. Once the data is consumed, the tail pointer of the ring buffer is updated to indicate that the card is finished with that memory region.

Furthermore, the keyboard app extension and the keyboard app are installed as a single package whose components are not supposed to communicate, hence why I brought this up.

If this can be reproduced on the iPhone, it can lead to 3rd party keyboards exfiltrating data. By default, keyboard app extensions are sandboxed away from their owning applications [0], but they may communicate with the app over this channel and leak data. It's not as easy as I describe because the app would have to be alive and scheduled on the same cluster, but it's within the realm of possibility.

[0]: https://developer.apple.com/library/archive/documentation/Ge...

Comments URL: https://news.ycombinator.com/item?id=26088448

Points: 1

# Comments: 0