dua; LLM hax0rz; DuckDB VSS

Our semi-regular AI-focused edition is back with some tooling and a somewhat disconcerting development in the land of AI & cyber.

dua

I know what you’re gonna say… “Why is a Rust-based disk-usage thingy in the AI edition?”

We’ll make this quick.

For work, I hack around with local models, and — despite having a bonkers maxed out Mac Studio — I get the “nearly out of disk space” reminders more often than I care to mention.

A big reason for that is the places various AI tools dump HuggingFace (et al.) models (another is data I use with the models). These models are usually YUGE and I regularly forget which ones are cached where by what tool.

So, dua helps me see things at-a-glance and very quickly. I tend to use it in interactive mode (screenshot in the section header). It’s faster than fd, and I do not need to remember fd CLI incantations.

The one thing I’d like it to have is JSON output, but for how quickly it lets me free up disk space, I’ll gladly live with that limitation.

LLM hax0rz

This is a somewhat disconcerting bridge of my cyber and data science worlds that seemed to fit in well for a ThursdAI edition.

“LLM Agents can Autonomously Exploit One-day Vulnerabilities” is a recent paper by Richard Fang, Rohan Bindu, Akul Gupta, and Daniel Kang that shows LLM agents can autonomously exploit real-world system vulnerabilities, specifically one-day vulnerabilities, which are security flaws that have been disclosed but not yet patched.

The study involved creating a benchmark of 15 real-world one-day vulnerabilities, sourced from the Common Vulnerabilities and Exposures (CVE) database and academic papers, focusing on open-source software for reproducibility. The vulnerabilities ranged from website exploits to container management software and vulnerable Python packages (isn’t that all of them? 🙃), with over half classified as high or critical severity.

The authors developed an LLM agent using the GPT-4 model, which was given access to tools such as web browsing elements, a terminal, web search results, file creation and editing, and a code interpreter. The agent was able to exploit 87% of the vulnerabilities when provided with the CVE description, a significant contrast to the 0% success rate of other models and open-source vulnerability scanners tested.

The findings highlight that without the CVE description, GPT-4’s success rate dropped to 7%, indicating that while the model is highly capable of exploiting known vulnerabilities, it struggles with identifying vulnerabilities on its own. This suggests that the current threat posed by LLMs is primarily in the context of known vulnerabilities rather than discovering new ones.

The cost analysis provided in the paper shows that using GPT-4 for exploiting vulnerabilities is substantially cheaper than employing human cybersecurity experts, with the potential for further cost reductions as technology advances. We’ve seen similar benefits on the defender side, with AI-driven payload clustering analysis helping our folks triage and write detections in a fraction of the time it used to. With the advent of the findings in this paper, we’re likely going to redouble our efforts to increase the speed of this process and technical performance of the models we rely on.

It’s a fairly accessible read, both in terms of the “data science” aspect of the paper and the “cybersecurity” aspect.

DuckDB VSS

Yep, I (again) hear your “I thought this was your AI edition?”. Trust me, it is!

DuckDB VSS is an experimental extension for DuckDB that adds indexing support to accelerate vector similarity search (y’know, how most of you are processing embeddings?) using DuckDB’s new fixed-size ARRAY type. The extension is based on the usearch library and provides a custom index type, in this case a HNSW index, that can be used to accelerate queries that use an ORDER BY clause evaluating one of the supported distance metric functions against the indexed columns and a constant vector, followed by a LIMIT clause.

The index supports Euclidean distance, Cosine similarity, and Inner product distance metrics, which correspond to the array_distance(), array_cosine(), and array_inner_product() DuckDB functions respectively.

The normal insert/update/delete ops are supported, but deletes are not immediately reflected and can cause the index to grow stale over time. The PRAGMA hnsw_compact_index() function can be used to re-compact the index.

Only vectors consisting of FLOAT values are supported, and the index must fit entirely in RAM memory (this is likely a deal breaker for some folks).

The index is persisted to disk when DuckDB performs a checkpoint, and deserialized back into memory on restart, which may take some time for large indexes.

You’re likely better off using some of the VSS tooling that’s been around a bit, but I’m pretty excited to see this land in DuckDB land, and will keep tabs on it/report back as it improves.

FIN

Remember, you can follow and interact with the full text of The Daily Drop’s free posts on Mastodon via @dailydrop.hrbrmstr.dev@dailydrop.hrbrmstr.dev ☮️