> though this would be a much more sophisticated exploit and is maybe a bit of a reach.
Not necessarily. I have successfully exploited stack buffer overflows in major products despite stack canaries, ASLR, and DEP. It largely depends on context; if the vector is something that can be hit repeatedly, such a webform that that takes a cert or whatever, that simplifies things a lot versus something like a file format exploit, where you probably only get one chance. While I haven't analyzed this vulnerability, I would absolutely assume exploitability even if I couldn't see a way myself.
It depends on what mitigations are in place and the arrangement of the stack. Even with stack canaries, having an unfortunate value on the stack e.g. a function pointer can still be quite dangerous if it can be overwritten without hitting any of the stack canaries.
While there's some overlap in methodologies and back-and-forth with various escalations, so-called malware is distinct from software exploits. Malware can be delivered without an exploit and quite often is. Social engineering is highly effective.
I was hit by this. Could RDP into machines using the regular client, but could not access Dev Boxes via Windows App. Getting real sick of the low quality AI slop.
Thanks for taking the time to respond, and apologies for the contentiousness. I'm a jaded old man suffering from severe LLM fatigue, so I may have come off a bit harsh. Your write-up was a good read, and while I might be critical of your methodology, what you did clearly worked, and that's what matters in the end. Best of luck with your project, especially the go lib fork.
The problem is hallucinations. It's incredibly frustrating to have an LLM describe an API or piece of functionality that fulfills all requirements perfectly, only to find it was a hallucination. They are impressive sometimes though. Recently I had an issue with a regression in some of our test capabilities after a pivot to Microsoft Orleans. After trying everything I could think of, I asked Sonnet 4.5, and it came up with a solution to a problem I could not even find described on the internet, let alone solved. That was quite impressive, but I almost gave up on it because it hallucinated wildly before and after the workable solution.
The same stuff happens when summarizing documentation. In that regard, I would say that, at best, modern LLMs are only good for finding an entrypoint into the docs.
Oh come on, the fact that the author was able to pull this off is surely indicative of some expertise. If the story started had started off with, "I asked the LLM how to capture network traffic," then yeah, what I said would not be applicable. But that's not how this was presented. tcpdump was used, profiling tools were mentioned, etc. It is not a stretch to expect somebody who develops networked applications knows a thing or two about protocol analysis.
Sure, but that is aside from my original point. If somebody:
a) Has the knowledge to run tcpdump or similar from the command line
b) Has the ambition to document and publish their effort on the internet
c) Has the ability identify and patch the target behaviors in code
I argue that, had they not run to an LLM, they likely would have solved this problem more efficiently, and would have learned more along the way. Forgive me for being so critical, but the LLM use here simply comes off as lazy. And not lazy in a good efficiency amplifying way, but lazy in a sloppy way. Ultimately this person achieved their goal, but this is a pattern I am seeing on a daily basis at this point, and I worry that heavy LLM users will see their skill sets stagnate and likely atrophy.
>Is that because wireshark can't do that just from packet captures?
Well, not quite. I think it's more that nobody has taken the time to implement it. That's not to say such an implementation would automatically decrypt the traffic from a capture with no extra leg work, of course. Wireshark dissectors have user configurable preferences, and presumably this would be where captured secrets could be set for use. This is how it handles TLS decryption [1], which works beautifully.
What are you even trying to say? I suppose I'll clarify for you: Yes, I'm confident I could have identified the cause of the mysterious packets quickly. No, I'm not going to go through the motions because I have no particular inclination toward the work outside of banter on the internet. And what's more, it would be contrived since the answer has already shared.
Not even remotely accurate. While the dissector is not as mature as I thought and there's no built-in decryption as there is for TLS, that doesn't matter much. Hint: every component of the system is attacker controlled in this scenario.
Well, I spent a good part of my career reverse engineering network protocols for the purpose of developing exploits against closed source software, so I'm pretty sure I could do this quickly. Not that it matters unless you're going to pay me.
Interesting, I thought it was possible to decrypt SSH in Wireshark a la TLS, but it seems I'm mistaken. It still would have been my first goto, likely with encryption patched out as you stated. With well documented protocols, it's generally not too difficult deciphering the raw interior bits as needed with the orientation provided by the dissected pieces. So let me revise my statement: this probably would have been a fairly easy task with protocol analysis guided code review (or simply CR alone).
The reliance on LLMs is unfortunate. I bet this mystery could gave been solved much quicker by simply looking at the packet capture in Wireshark. The Wireshark dissectors are quite mature, SSH is covered fairly well.
>Current tests suggest it is not likely related to any other known psychedelic compound. For one, the trips it produces are unusually long, commonly lasting 12 to 24 hours, and in some cases even causing hospital stays of up to a week.
Plenty of common psychedelics have durations in excess of 12 hours. Some even in excess of 24 e.g. high doses of 2C-P. This may be a novel compound, but the duration is not necessarily an indicator.
At risk of being called out for my ignorance (I am still new to GPU development and have only limited experience with CUDA), it seems to come down to how appropriate the execution model is to the work e.g. SIMT vs SIMD here.
My brother's now ex-wife learned the hard way about the challenges of soft delete. Too bad about the contents of that SQLite database, but his knowing was for the better.
Maybe things are different now, but I'm on my third year with my current employer, and I found them organically, sending my resume out on Indeed. Admittedly the MS stuff was largely kicked off by contacts, but that's the only instance throughout my career. And those connections were gained through other work, of course.
This is interesting, but in most cases the challenge is finding a truly exploitable bug. If LLMs can get to the point where they can analyze a codebase and identify vulnerabilities, we're going to see some shit. But as of right now, this looks like a medium-to-low complexity bug that any competent exploit developer could work with easily.
Interesting Microsoft is mentioned as recently dropping degree requirements. First time I worked there as an FTE without a degree was 2012. I don't see this as any sort of turn of events in the industry. It's always been "degree or equivalent experience" as far as I can remember.
Writing software that works containerized isn't that bad. A lot of the time, ensuring cross platform support for Linux is enough. And docker is pretty easy to use. Images can be spun up easily, and the orchestration of compose is simple but quite powerful. I'd argue that in some cases, it can speed up development by offering a standardized environment that can be brought up with a few commands.
Kubernetes, on the other hand, seems to bog everything down. It's quite capable and works well once it's going, but getting there is an endeavor, and any problem is buried under mountains of templatized YAML.
>I'm easily getting twice my workload done with AI, and I'm not even leveraging the full extent of the tools.
It seems that every person who says this never elaborates on the nature of their work. What exactly are you writing? What languages? Technologies? What does the LLM assist with? In what ways does it hamper more than help?
I ask these questions because I have yet to see any meaningful, real world application of AI at my job. There's definitely interest, but every exploratory effort seems to fall flat, sometimes comedically so e.g. recently we had Sonnet 4.5 recommend some JavaScript for a UI hang we were looking into. It also recommended we use WebWorkers to improve perf. Sounds great. Looks great, with nice markdown and whatnot. Too bad it was a legacy MFC application written in C and C++.
What was his role? How did he slow the project down? I ask because quite often, the value of "soft skills" is exaggerated. In almost 20 years of software engineering I have met some of the worst personalities imaginable. Yet, I cannot think of a single time somebody's personality got in the way to such an extent it slowed the project down. Some problems can't be solved by average people. In such cases, bad social skills with above average intellect will go farther than average intellect with good soft skills.