| Website | https://robert.sesek.com |
| @rsesek |
Woah, in macOS 15.4, two of my favorite syscalls are finally 'public' and documented!
"fileport_makeport(2) and fileport_makefd(2) are now APIs with manual pages. (66571768) (FB8270900)"
https://developer.apple.com/documentation/macos-release-notes/macos-15_4-release-notes
Chromium has been using them for at least 6 years, when I implemented the IPC Channel using Mach messages.
Cool project: "Nepenthes" is a tarpit to catch (AI) web crawlers.
"It works by generating an endless sequences of pages, each of which with dozens of links, that simply go back into a the tarpit. Pages are randomly generated, but in a deterministic way, causing them to appear to be flat files that never change. Intentional delay is added to prevent crawlers from bogging down your server, in addition to wasting their time. Lastly, optional Markov-babble can be added to the pages, to give the crawlers something to scrape up and train their LLMs on, hopefully accelerating model collapse."
I've recently been working to understand what triggers certain TCC prompts on macOS. During this investigation I noticed something that many prior analyses of TCC overlook: TCC prompts can be triggered not only by system frameworks, but by the Sandbox kernel extension in response to rules defined by the platform sandbox policy.
My latest blog post documents the sandbox features behind this and provides examples of some of the responsible sandbox policies.
https://bdash.net.nz/posts/tcc-and-the-platform-sandbox-policy/
Another big step towards becoming a security boundary: today we’re expanding the VRP for the V8 Sandbox
* No longer limited to d8
* Rewards for controlled writes are increased to $20k
* Any memory corruption outside the sandbox is now in scope
See https://bughunters.google.com/about/rules/chrome-friends/5745167867576320/chrome-vulnerability-reward-program-rules#v8-sandbox-bypass-rewards for more details.
Happy hacking!
ATTENTION As of 4 February 2024, Chromium has migrated to a new issue tracker, please report security bugs to the new issue tracker using this form . Please see the Chrome VRP News and FAQ page for more updates and information. The Chrome...
Here's a thing I noticed today. macOS Sequoia changes how non-notarized apps are handled on first launch. I couldn't override by doing the control-click > Open > yes really Open dance. Instead, I had to go to the Settings app, to the Security screen, and click there to allow it to open. At which point it asked me AGAIN if I wanted to open it, and then had to put in my password!
I get the impulse about making it harder to socially engineer bad apps from opening, but... this is ridiculous.
I learned about a new information classification system used by the US Federal Reserve. Documented here: https://www.federalreserve.gov/monetarypolicy/files/FOMC_InformationSecurityProgram.pdf.
You can see the markings on Jerome Powell's documents in this photo: https://images.wsj.net/im-758621/?width=4000&size=1
Not as interesting as intelligence classification system, but there are some obvious similarities: classification levels, handling directives, and "//" separators. You can find a surprising number of documents online labeled "FRSONLY".
(CC: @Electrospaces )
In my last blog post, I discussed why people often view the web as a uniquely unsuited platform for implementing end-to-end encryption (E2EE). This view is that the web doesn’t offer a long-term trustable notion of what the application is. In that earlier post, I explored the idea of treating the application as untrustworthy and isolating sensitive data from it. In this post, I’m going to pontificate on whether web applications are truly less trustworthy than native applications, especially in an E2EE setting, and if so, how we should bridge the gap. The gap is narrower than it appears at first glance, especially with desktop applications. To close it, though, the devil is in the (UX- and deployment-related) details.
tante
bdash
Samuel Groß
Jason Snell
sam henri gold
Emily Stark