You can imagine a pipeline that looks at individual source files or functions. And first "extracts" what is going on. You ask the model:
- "Is the code doing arithmetic in this file/function?"
- "Is the code allocating and freeing memory in this file/function?"
- "Is the code the code doing X/Y/Z? etc etc"
For each question, you design the follow-up vulnerability searchers.
For a function you see doing arithmetic, you ask:
- "Does this code look like integer overflow could take place?",
For memory:
- "Do all the pointers end up being freed?"
_or_
- "Do all pointers only get freed once?"
I think that's the harness part in terms of generating the "bug reports". From there on, you'll need a bunch of tools for the model to interact with the code. I'd imagine you'll want to build a harness/template for the file/code/function to be loaded into, and executed under ASAN.
If you have an agent that thinks it found a bug: "Yes file xyz looks like it could have integer overflow in function abc at line 123, because...", you force another agent to load it in the harness under ASAN and call it. If ASAN reports a bug, great, you can move the bug to the next stage, some sort of taint analysis or reach-ability analysis.
So at this point you're running a pipeline to:
1) Extract "what this code does" at the file, function or even line level.
2) Put code you suspect of being vulnerable in a harness to verify agent output.
3) Put code you confirmed is vulnerable into a queue to perform taint analysis on, to see if it can be reached by attackers.
Traditionally, I guess a fuzzer approached this from 3 -> 2, and there was no "stage 1". Because LLMs "understand" code, you can invert this system, and work if up from "understanding", i.e. approach it from the other side. You ask, given this code, is there a bug, and if so can we reach it?, instead of asking: given this public interface and a bunch of data we can stuff in it, does something happen we consider exploitable?
That's funny, this is how I've been doing security testing in my code for a while now, minus the 'taint analysis'. Who knew I was ahead of the game. :P
In all seriousness though, it scares me that a lot of security-focused people seemingly haven't learned how LLMs work best for this stuff already.
You should always be breaking your code down into testable chunks, with sets of directions about how to chunk them and what to do with those chunks. Anyone just vaguely gesturing at their entire repo going, "find the security vulns" is not a serious dev/tester; we wouldn't accept that approach in manual secure coding processes/ SSDLCs.
In a large codebase there will still be bugs in how these components interoperate with each other, bugs involving complex chaining of api logic or a temporal element. These are the kind of bugs fuzzers generally struggle at finding. I would be a little freaked out if LLMs started to get good at finding these. Everything I've seen so far seems similar to fuzzer finds.
I think there is already papers and presentations on integrating these kind of iterative code understanding/verificaiton loops in harnesses. There may be some advantages over fuzzing alone. But I think the cost-benefit analysis is a lot more mixed/complex than anthropic would like people to believe. Sure you need human engineers but it's not like insurmountably hard for a non-expert to figure out
Hey jstsch, would you mind answering some questions?
- Did you need/use an electrician to set this up?
- How much KWh capacity do your batteries have?
- What about fire safety? Did you install outside, or inside?
- I assume dec/jan are the months you're not fully self-sufficient, are you allowed to charge from grid to do arbitrage over time, or is that another can of worms?
Set it up myself, mostly. Some specific tasks like bringing three-phase power to the garage and hooking up the breaker box I did with an electrician. But installing an additional circuit inside the breaker box, or putting new conduit up, is easy to do safely yourself. Pre-wired breaker boxes can be configured online and are cheap.
The battery is 16kWh. Effectively around 14kWh, since you never fully discharge. LiFePo4, so no chance of spontaneous combustion like other battery chemistries.
I'd say the months Nov→Feb are tricky, although since I have quite a bit of excess solar capacity there are even in December plenty of days where the battery pulls me through the night.
Charging/discharging from/to the grid is possible, since I have a retrofit inverter (AC to battery), but not doing it yet, have to do a bit more research (dynamic pricing, tax is >50% of the kWh price in NL, etc).
> But installing an additional circuit inside the breaker box, or putting new conduit up, is easy to do safely yourself.
UK specific note: note that since the changes in 2013 under the ""Part P"" building regulations, almost all electrical work other than trivial replacement is illegal to DIY. Additionally, renewables work requires extra MCS certification.
Which is why balcony solar is a good deal, it requires none of that.
> 1) Are there any reliable open-source PAM alternatives or privilege elevation tools for Windows that handle this "per-app" scenario effectively?
I would look into:
- creating an account to run the apps you need, giving the user the password to this account, or create a shortcut to execute the browser with "runas"
Now here my ideas break down, but I think you could get far with:
- For that account, (log in as it, open IE), and configure the "secure zone" / "internet zone" as "insecure". Allow all active X components to load.
- As an admin:
1) Start/go into "Component services" (run: "DCOMCNFG")
2) Right-click "my computer" -> properties:
3) "Edit default" for both activation and access permissions and for both default and limits:
3.1) Give the new user basically all privileges.
3.2) Review if the process now works with the lower privileged user.
3.3) Reduce privileges as far as possible until the process breaks. Stop there.
4) Consider that "Remote launch" and to a lesser extent "remote access", exposes the computer to remote control _if_ the credentials for the user with those privileges are leaked.
5) Consider if this is worth the risk, if yes, leave the configuration. You're done :)
Some unconnected suggestions:
- The page that loads the active X will have a number of GUIDs in them, those are the COM classes that back the active X objects (just DCOM objects). You can look those up in the registry to find the implementing .dll files, paths, etc. etc.
- You _can_ whitelist / safelist individual COM / ActiveX packages if you need to but I've forgotten the exact way to do this, and also what exactly it allows you to do ;). You may find: https://github.com/tyranid/oleviewdotnet useful to research this, it has a tab for "pre approved objects", I think if you get your ActiveX's in that list they'd be able to run under the user you need to. If you can access the HTML page you need to open which loads the ActiveX components, you can search for the CLSIDs in that tool, and perhaps figure out where they are. I'm 90% you can move the CLSIDs to a registry key to put them on the safe list, perhaps that's already enough to bypass the "local admin required".
You may be able to do the launch permissions per com object in `DCOMCNFG`.
> 2) When dealing with hostile ActiveX components, are there specific legacy behaviors (beyond obvious file/registry Access Denied) I should be looking for in my Procmon captures?
If you mean, _abused_ ActiveX components, not much you can do. Obviously yes, access to registry, etc. But if the attacker gets to a point they can load _arbitrary_ dcom objects and talk to them, it's game over, that's RCE.
If you mean, how to find which COM objects I need to allow. Better luck with `oleviewdotnet` I think. And open that page and look for the CLSIDs to know where to start. You can search in the registry and oleview to find them once you have the CLSIDs (guids).
> 3) How do you isolate this kind of hardcoded legacy requirement when there is zero budget for commercial enterprise tools?
I assume you are on a much older version of windows? Xp? 2000?, Then I'm not sure.
The bar to ingest unstructured data into something usable was lowered, causing more people to start doing it.
Used to be you needed to implement some papers to do sentiment analysis. Reasonably high bar to entry. Now anyone can do it, the result: more people doing scraping (in less competent scrapers too).
> Your company can scream to anyone that listens that all the competition is AI SLOP, but when hundreds of companies are pitching the same solution, your one voice will get lost.
If you cannot out compete "AI SLOP" on merit over time (uptime? accuracy? dataloss?), then the AI SLOP is not actually sloppy...
If your runway runs out before you can prove your merit over that timeframe, but you are convinced that the AI is slop, then you should ship the slop first and pivot onec you get $$ but before you get overwhelmed with tech depth.
Personally, I love that I can finally out compete companies with reams of developer teams. Unlike many posters here, I was limited by the time (and mental space) it takes to do the actual writing.
It certainly seems possible that AI slop could be flawed in some major ways while still competing well in the market: security is usually invisible to users until it isn’t, similar uptime and bugs, accessibility can be ignored if you don’t mind being an unethical person.
Then again this is also often a flaw with human-generated slop, so it is hard to say what any of this really means.
I guess the point is that startups are dead because scaling up becomes harder, doesn’t mean that organic growth is harder. In fact, the potential ways forward offered by the article are not really dependent on VC funding.
But you're not just trying to out compete one AI slop, you must compete with ALL of them. And over time the AI slop to thoughtful company ratio is only going to increase
IMO it's shoddy. Anybody can get hacked, that's true. But a modern corp that has tried to defend itself should have multiple layers of defenses against complete pwnage.
If you've paid attention in the last 10 (or even 5) years as a company, and did some pentests and redteams, you've seen how you could be breached, and you took appropriate steps years ago.
A non-shoddy company will have:
- hardened their user endpoints with some sort of modern EDR/detection suite.
- Removed credentials from the network shares (really).
- Made sure random employees are not highly privileged.
- Made sure admin privileges are scoped to admin business
roles (DBA admin is not admin on webservers, and vice-versa).
- Made sure everyone is using MFA for truly critical actions and resource access.
- Patched their servers.
- Done some pentests.
This won't stop the random tier 2 breach on some workstation or forgotten server still hooked up on prod/testing, but it will stop the compromise _after_ that first step. So sure, hackers will still shitpost some slack channel dumps, but they won't ransomware your whole workstation fleet...
I guess you forgot the most important part: making sure your security and devops teams and people in company management follow exactly the same protocol as everyone else with no exception.
Because big bosses hate it when their PC don't just let them run whatever they want and they are not allowed to VPN into network from their home or their grandma desktop because they like her very much.
Also any Linux nerd sysadmin dude (like me) who know better is another type of person who hate following rules.
1) What are the limitations of the scaling you do? Can I do this programmatically? I.e. send some requests to get additional pods of a specific type online?
2) What have you done in terms of security hardening? you mention hardened pods/cluster, but specifically, did you do pentest? Just follow best practice? Periodic scans? Stress tests?
Thanks for your questions!
1) The platform provides a control plane to help you deploy the cluster on your own Hetzner account, so you are in control of resources and pay direct usage costs to Hetzner.
2) Because you have full access to kubernetes cluster and it runs on your own Hetzner account, the security of the cluster is a shared responsibility and you can fine tune the configuration according to your requirements. The platform security is totally our responsibility. We try to follow best practices and internal penetration tests were conducted, but we're still in beta and try to see if there's interest for such product before launching the stable version.
Even big customers have a use for what you've built in high security areas they might have. Think swift alliance servers in a specialized network segment in financials, or perhaps sensitive medical information in health care?
I think you should not have any issues integrating with legacy AD, but know bigger enterprises have mostly moved to online IdPs. Integrating with legacy AD will make your product also likely less secure. Maybe not the way to go?
> What is an identity provider (IdP)?
>
> An identity provider (IdP) is a service that stores and verifies user identity. IdPs are typically cloud-hosted services, and they often work with single sign-on (SSO) providers to authenticate users.
Get your interface id first, you're looking for the IDX number. There might be several.
ping ff02::1%LAN_INTERFACE_ID
So, example:
```
ping ff02::1%22
```
Windows ping wrt the firewall is not very smart, it won't let the response packets through. So you need to disable your firewall to see systems responding.
Sadly, ping won't display the src address. It will state that "ff02::1%22" responded... But if you look in wireshark you can tell the other systems on your network received and responded to the packet.
- "Is the code doing arithmetic in this file/function?" - "Is the code allocating and freeing memory in this file/function?" - "Is the code the code doing X/Y/Z? etc etc"
For each question, you design the follow-up vulnerability searchers.
For a function you see doing arithmetic, you ask:
- "Does this code look like integer overflow could take place?",
For memory:
- "Do all the pointers end up being freed?" _or_ - "Do all pointers only get freed once?"
I think that's the harness part in terms of generating the "bug reports". From there on, you'll need a bunch of tools for the model to interact with the code. I'd imagine you'll want to build a harness/template for the file/code/function to be loaded into, and executed under ASAN.
If you have an agent that thinks it found a bug: "Yes file xyz looks like it could have integer overflow in function abc at line 123, because...", you force another agent to load it in the harness under ASAN and call it. If ASAN reports a bug, great, you can move the bug to the next stage, some sort of taint analysis or reach-ability analysis.
So at this point you're running a pipeline to: 1) Extract "what this code does" at the file, function or even line level. 2) Put code you suspect of being vulnerable in a harness to verify agent output. 3) Put code you confirmed is vulnerable into a queue to perform taint analysis on, to see if it can be reached by attackers.
Traditionally, I guess a fuzzer approached this from 3 -> 2, and there was no "stage 1". Because LLMs "understand" code, you can invert this system, and work if up from "understanding", i.e. approach it from the other side. You ask, given this code, is there a bug, and if so can we reach it?, instead of asking: given this public interface and a bunch of data we can stuff in it, does something happen we consider exploitable?
reply