OneLessThing

It's not that the Chinese companies are right, it's that Anthropic has no place to complain about stealing.

I see it as the same problem of when to accept button input. In my view having the button give "ample warning a material change is about to happen" is making the button do something more than "one job." But maybe you're right if your point is that if you're showing a button it should do the work it says it will do.

They are both about when it is best to accept user input. In the specific example with rotating images nothing covers or moves the buttons so it is not relevant. My impression of the article was that the buttons one job was to accept input always, my argument is that there are times it's okay to not accept input, for example the short time after certain layout changes

It's not so simple. There are times where you intend to tap one thing and something else appears underneath your finger instantaneously. So sometimes while rendering a layout you want to stop accepting input.

Yeah :/ that’s how I read it too. It would make more sense if they motivated the reason to find libc because like you said you could likely just use the non aslr gadgets exclusively. I think the author tried to use non aslr gadgets but had issues so went to the approach of using the GOT libc address and called that approach “bypassing ASLR”.

It’s a matter of opinion I guess. In the early days of ASLR it was common to look for modules that were not position independent for your ROP chain and that process was probably called bypassing aslr. These days we’d probably just call that not being protected by aslr.

Good job. It’s early 2000s level stuff but it’s still exciting when it’s happening on your desk. There are lots of options in this scenario outside of bypassing ASLR so I do find it odd to be the main feature of the title, but a fun read nonetheless.

It’s fun working on targets with a less established research history. And I love a soup to nuts writeup, Thanks.

This is exactly my problem with LLM C code, lack of confidence. On the other hand, when my projects get big enough to the point where I cannot keep the code base generally loaded into my brains cache they eventually get to the point where my confidence comes from extensive testing regardless. So maybe it's not such a bad approach.

I do think that LLM C code if made with great testing tooling in concert has great promise.

This is why I love C. You can build these guard rails at exactly the right level for you. You can build them all the way up to CPython and do garbage collection and constant bounds checking. Or keep them at just raw pointer math. And everywhere in between. I like your approach. The downside being that there are probably 100,000+ bespoke implementations of similar guard rails where python users for example all get them for free.

It's funny the author says this was 90% written without AI, and that AI was mostly used for the json code. I think they're just new to C.

Trust me I love C. Probably over 90% of my lifetime code has been written in C. But python newbies don't get their web frameworks stack smashed. That's kind of nice.

It's interesting to hear these takes. I've never had problems catching unsigned wrap bugs with plain old memory sanitizers, though I must admit to not having a lot of experience with ubsan in particular. Maybe I should use it more.

I agree that it reads really well which is why I was also surprised the quality is not high when I looked deeper. The author claims to have only used AI for the json code, so your conclusion may be off, it could just be a novice doing novice things.

I suppose I was just surprised to find this code promoted in my feed when it's not up to snuff. And I'm not hating, I do in fact love the project idea.

Heres a link to the the problem I found: https://alew.is/lava.html

There is a heap overflow in the http parser. Should I spoil it or let people find it on their own?

Okay I did the simulation. I don't think this strategy actually works, but I initially thought it might like you did. One such nash equillibrium my sim found was having the Ballmer player mix between picking either end of the range (not always 1 or 100 but around those numbers). I have the Ballmer player winning with around $.85-$1.00 EV per round. The resulting player strategy was to also try to start their binary search at the extreme ends of the range and hope they guessed the right side. It's kind of like the soccer penalty kick dynamic between the shooter and goalie. Goalie wants to pick the same side, shooter wants opposite sides. But with 100 choices, the goal is too wide I think.

I now think that not constraining the players remaining choices to follow binary search pattern would completely change the resulting equilibrium and improve the results for the player. But that would be more computationally demanding to calculate because there's a strategy choice for every range of choices. And also I've avoided work for 2 hours by working on this so that's not great haha. I _am_ curious what not constraining the player to binary search would do though...

Yes, this has been a trend for a little while now. For example this gist[1] gives linux boot parameters to make linux significantly faster and all it does is basically turn off all default security mitigations. I would make the distinction between vulnerabilities and "exploitable" vulnerabilities though. Mitigations usually give a runtime performance hit but don't remove the underlying flaws, it can just make it harder, or sometimes impossible, to escalate a little flaw into full blown code execution. But also know that offensive techniques advance along side defensive ones. For example ASLR was once considered the death of vulnerability research, but new methods and ideas were found and bypassing ASLR is now just part of the job. Each mitigation must be regularly evaluated against the state of the art, and against the cost to performance (and complexity, etc.). You ideally don't want to be paying performance costs when they aren't helping security.

Rust, Zig, and others, are additionally paying compile time performance costs to remove some underlying vulnerabilities. Which is interesting and probably a good thing for software.

[1] https://gist.github.com/jfeilbach/f06bb8408626383a083f68276f...

I am this person. I work as a researcher finding 0-days.

From the employee perspective: Wages are equal. Big Tech work is less interesting (build big bug finding machines that find have high quantity of bugs) and report the bugs that sit into some bug tracker only to maybe be fixed in 3 months. Offensive security work is more interesting. It requires intimate knowledge of the systems you research, since you only need a handful and the shallow ones get found by Big Tech. You must go deep. Additionally offensive security requires the know-how to go from vulnerability to code execution. Exploitation is not an easy task. I can't explain why engineers work for companies that I deem immoral, but that's probably because they don't feel the same way as I do.

From the employer perspective: How much does the rate of X vulnerabilities per year cost me? If our code has bugs but is still considered the securest code on the market, it may not benefit the company to increase the security budget. If the company expands the security budget then which division is getting cut because of it, and what is the net result to the company health?

If you want to fix the vulnerabilities you need to make the price of finding and exploiting them higher than the people buying them can afford. And you must keep the price higher as advances in offensive security work to lower the price of finding and exploiting them. Since defensive companies don't primarily make money from preventing bugs and offensive companies do primarily make money by finding bugs, there is a mismatch. The ultimate vulnerability in a company, or any entity, is finite resources.

I love thinking with a pencil/pen compared to a keyboard since there seem to be so many more expressive possibilities: Size, Position, Drawings, Arrows, etc. Not to mention research suggesting it's better for memory.

This is a demo of making a handwritten blog but using SVG rather than images. There are advantages of this including but not limited to reducing bandwidth. This blog was made on a tablet, images of the handwriting exported to Inkscape, and SVG placed into a html wrapper. I really wish the workflow from pen, pencil, and paper to blog post was smoother.

I experimented with this approach on my blog[1]. I had an image of the handwritten blog post and used a feature in Inkscape to get SVG and make clickable text. I decided to place a little plain text in there to help Google search crawlers know what content is on the page. I really would prefer handwriting more.

My problems boil down to just that flow of the tools sucked. I didn't want to have to attach multiple pages together. Inkscape was honestly a bit clunky to work with and I didn't have any personal tools to generate the full html from the svg.

I might just be inspired to try again though.

[1] https://blog.alew.is/insertionsort.html

If we improve our programming languages and practices to make code bases more easily understood we will simply increase the scope of what the projects attempt to solve, not reduce their complexity. While this is a good for software it still means we’re going to be moaning about working on complex software.

It’s like how the increased economic productivity due to technology has not made the work week shorter.

Well I think there are laws that vary across counties and cities and that’s an interesting idea to apply abortion to.

Having different laws for different individual people seems like a really bad idea though.

If you read the resulting articles you'll find a few of them suggest that all the deaths were staged or committed by Ukrainians. Headlines like "The truth is out there..." or "Global lies..." are examples. There still are many results from mainstream western media on the other hand.

Google, in contrast, has zero results implying the deaths were staged or committed by Ukrainians.

I had the same experience when my brain decided that I get the point of the sentence and where it was going. Perhaps if there was actual content in the sentence this wouldn’t have happened.

Well we’ve kind of already started exploring that option with unikernels. Compile each app as its own complete software stack.

https://en.m.wikipedia.org/wiki/Unikernel

If you aren't already reading it, may I suggest you checking out Scott Robertson's "How To Draw: Drawing And Sketching Objects And Environments From Your Imagination"

That’s exactly what I expect in about 3-5 years. I particularly have my eye on BitTorrent modifications like webtorrent which may get the viewing experience even closer to a paid streaming service.

Did this line get removed from the blog post?

I looked into it[1], their net profit margins were 32% last quarter. 36% gross margins on hardware products (iPhone, Mac, etc) and 70% gross margins on services (AppleCare, Cloud Services, etc.). However services only comprise 19% of their sales, the other 81% of their sales are from hardware products (mostly iPhones). Their service sales seem to all stem from them making the hardware. For example the AppStore walled garden is protected by the hardware, AppleCare services their hardware, and Cloud services are integrated into their devices, etc. It may be possible in the future for apple to get high margin "service" sales from an Apple Car App Store, buying games and movies for your self driving car, for example. Regardless I'd definitely consider Apple a hardware company.

[1] https://www.apple.com/newsroom/pdfs/FY21_Q2_Consolidated_Fin...

I absolutely agree that asm should be taught for computer fundamentals but I really LOL'd at assembly teaching how CPU works without abstraction. There is tons of abstraction below assembly -- see Microcode. It's this mistake in thinking that lets things like spectre/meltdown sit in computers for decades. But for the most part you're right, going down past assembly has not helped me understand __software__.

amd64 and arm64 have no default heap configuration, they don’t even know what the heap is. Same is true for their 32 bit equivalents. If he said Linux based OS’s or Windows have non executable heaps then I’d have kept watching because yeah you could assume he meant “by default”. Instead he blamed the processor and not only that but only 64 bit processors. It’s a massive misunderstanding on his part.

“Exploit authors don’t really care about stack cookies, especially with today’s techniques like rop, jop, srop”

None of those suggested techniques address stack cookies but okay, I’ll keep listening.

“We can overwrite parts of the heap, the problem is the heap is not executable on amd64 and arm64”

And that’s where you’ve lost me. Processor has no concept of the “heap.” Whether or not you can make heap pages executable is up to the OS, and all common OS’s let you do this. Not only that, but the browser you’re using to view this very page is probably using executable allocations right now to JIT the (very little) JavaScript on this site.