Stories with Tag fuzzing

• I used o3 to find a remote zeroday in the Linux SMB implementation

  permalink

  Posted: 2025-05-24 14:25:45

  Verbose tl;dr

  The author discovered a critical remote zero-day vulnerability (CVE-2025-37899) in the Linux kernel's SMB implementation, ksmbd, using the o3 fuzzer. This vulnerability allows for remote code execution without authentication, potentially enabling attackers to compromise vulnerable systems. The flaw resides in the handling of extended attributes, specifically when processing EA metadata within SMB2_SET_INFO requests. The fuzzer pinpointed an integer overflow leading to a heap out-of-bounds write, which could then be exploited to gain control. The author developed a proof-of-concept exploit demonstrating arbitrary kernel memory reads and writes, highlighting the severity of the issue. A patch was submitted and accepted upstream, and distributions subsequently released updates addressing this vulnerability.

  Sean Heelan details the discovery and exploitation of CVE-2025-37899, a remote zero-day vulnerability within the Linux kernel's Server Message Block (SMB) implementation, specifically within the ksmbd kernel module. Heelan leverages the symbolic execution engine o3, a fork of the SymCC project, as the primary tool for vulnerability discovery.

  Heelan begins by outlining the appeal of ksmbd as a target. He explains that ksmbd is a relatively new, in-kernel SMB server implementation, presenting a fresh attack surface compared to the more established user-space Samba implementation. This newness implies less scrutiny and potentially a higher likelihood of undiscovered vulnerabilities. He also notes that targeting kernel-space vulnerabilities carries greater impact, potentially granting complete system control.

  He focuses on the ksmbd_read_data function, suspecting its complexity makes it a prime candidate for harboring bugs. After initial attempts to use SymCC directly proved computationally expensive, Heelan opted to use o3, a fork known for its optimized performance. He details the process of configuring o3 for this specific task, including compiling ksmbd for symbolic execution and setting constraints within o3 to narrow the scope of the symbolic analysis, thus making the process tractable. This involved specifying the size and content of the SMB packet being processed.

  Heelan identifies a particular code path related to how ksmbd handles the SMB2_READ request. This path deals with data compression and involves calculating the destination buffer size. He discovers a flaw in this calculation, where a specific sequence of input parameters can lead to an integer overflow. This overflow allows for an out-of-bounds write within the kernel memory.

  Heelan then meticulously explains the exploitation process. The integer overflow enables him to overwrite a specific 8-byte value in kernel memory. He carefully chooses the target address and the overwrite value to manipulate the modprobe_path variable. By altering this variable, Heelan redirects the kernel's module loading mechanism to load a malicious kernel module disguised as a legitimate one. This malicious module then grants him root privileges, effectively completing the exploit chain.

  Finally, Heelan reflects on the efficacy of o3 as a vulnerability discovery tool, emphasizing its speed and ability to handle complex code paths. He also highlights the potential for future improvements in symbolic execution technology and its growing role in uncovering security flaws. He notes the assigned CVE identifier for the vulnerability and mentions that a patch has been released, urging users to update their systems.

  • Linux
  • SMB
  • Samba
  • CVE-2025-37899
  • zero-day
  • Vulnerability
  • remote code execution
  • RCE
  • Exploit
  • Security
  • Kernel
  • O3
  • fuzzing
  • software testing

  Summary of Comments ( 178 )
  https://news.ycombinator.com/item?id=44081338

  Verbose tl;dr

  Hacker News users discussed the efficacy of using static analysis tools like O3, with some praising its potential while acknowledging it's not a silver bullet. Several commenters pointed out the vulnerability seemed relatively simple to spot, questioning the need for O3 in this specific case. The conversation also touched on the disclosure process and the discoverer's decision to publish exploit details before a patch was available, sparking debate about responsible disclosure practices. Some users criticized aspects of the write-up itself, such as claims about the novelty of O3's capabilities. Finally, the prevalence of memory safety issues in C code and the role of tools like Rust in mitigating such vulnerabilities were also discussed.

  The Hacker News post discussing the blog post about CVE-2025-37899 has generated a substantial number of comments, many of which delve into various technical aspects of the vulnerability and the process used to discover it.

  Several commenters commend the author's approach of using compiler optimizations (specifically -O3) to uncover the vulnerability. They note the ingenuity of leveraging a tool not typically associated with security research for this purpose. Some discuss how compiler optimizations, while designed to improve performance, can sometimes expose latent bugs by rearranging code in ways that reveal unexpected behavior.

  A few comments delve into the specific details of the vulnerability, discussing the memory management issues that ultimately lead to the exploit. They analyze how the -O3 optimization changed the code's execution flow in a way that made the bug manifest.

  The use of KASAN (Kernel Address Sanitizer) is also highlighted in the comments, with users praising its efficacy in pinpointing the source of the problem. The discussion touches on the importance of robust sanitizers in modern software development, especially for complex systems like the Linux kernel.

  Some commenters express concern about the implications of this discovery, pointing out the potential severity of a remote zero-day in such a widely used component. They discuss the potential impact on various systems and the importance of prompt patching.

  There's also a discussion around the responsible disclosure process, with commenters expressing appreciation for the author's approach and the timely patching of the vulnerability. The comments highlight the importance of coordinated disclosure to minimize potential harm while ensuring that users have access to necessary updates.

  A recurring theme in the comments is the relative simplicity of the vulnerability once it was uncovered. This leads to some speculation about why it wasn't discovered earlier, with suggestions ranging from the complexity of the codebase to the limitations of traditional testing methods.

  Finally, some commenters share their own experiences with similar vulnerabilities and discuss the challenges of finding and fixing bugs in complex systems. They offer insights into various debugging techniques and tools, contributing to a broader conversation about software security and best practices.

• Pwning the Ladybird Browser

  permalink

  Posted: 2025-04-30 23:59:09

  Verbose tl;dr

  The post details how the author exploited a vulnerability in the Ladybird web browser's JavaScript engine, specifically its handling of regular expressions. By crafting a malicious regular expression, they triggered a type confusion bug that allowed them to overwrite arbitrary memory locations. This ultimately led to achieving remote code execution within the browser process, demonstrating a serious security flaw. The exploit involved manipulating the internal representation of regular expressions and carefully controlling garbage collection to achieve the desired memory corruption. The author disclosed the vulnerability responsibly and it has since been patched.

  This blog post details a successful exploit against the Ladybird web browser, a project aiming to create a fast and lightweight browser utilizing the Qt framework and its own JavaScript engine, LibJS. The author, Jessie, meticulously outlines their journey from initial discovery to successful code execution, showcasing a sophisticated understanding of browser internals and exploit development.

  The vulnerability centers around LibJS's handling of JavaScript regular expressions, specifically within the RegExp optimization process. Normally, when a regular expression is deemed "hot" – meaning it's used frequently – LibJS attempts to optimize it for faster execution. This optimization involves generating native code. However, Jessie discovered a flaw in how LibJS manages the memory associated with these optimized regular expressions.

  The core issue resides in the logic for recompiling these optimized expressions. Under specific circumstances involving changing the global regular expression flags after the initial compilation, LibJS would inadvertently free the memory allocated to the optimized code without invalidating the cached pointer to that freed memory. This creates a "use-after-free" vulnerability, a dangerous condition where the browser continues to use a memory address that has been returned to the system. This stale pointer could then be overwritten with malicious code.

  Jessie demonstrates how they crafted a specific JavaScript regular expression and manipulation sequence that reliably triggers this use-after-free scenario. They then detail the painstaking process of achieving arbitrary code execution. This involves carefully understanding the memory layout after the free, identifying suitable areas for their payload, and meticulously crafting shellcode to overwrite the freed memory region. This shellcode, once executed by the unsuspecting browser attempting to reuse the freed memory for another regular expression operation, ultimately launches a calculator application as a proof-of-concept.

  The exploit is highly technical, leveraging intricate knowledge of LibJS internals, memory management, and x86-64 architecture. Jessie carefully walks through the steps involved, including the use of debugging tools to analyze memory states, identify offsets, and refine their payload. The post concludes with a reflection on the exploit development process and underscores the importance of robust memory management in browser engines to prevent such vulnerabilities. The vulnerability has been responsibly disclosed and subsequently patched by the Ladybird developers, highlighting the positive impact of security research within the open-source community.

  • Browser Exploitation
  • Ladybird Browser
  • LibJS
  • JavaScript engine
  • Vulnerability Research
  • Security
  • hacking
  • Web Browser Security
  • software vulnerability
  • fuzzing

  Summary of Comments ( 46 )
  https://news.ycombinator.com/item?id=43852096

  Verbose tl;dr

  HN commenters generally praised the technical deep-dive into Ladybird's internals, particularly appreciating the clear explanations of the exploits and mitigations. Several pointed out the importance of such security research for a young browser like Ladybird, helping it mature and improve its defenses. Some discussed the difficulty of fully securing JavaScript engines and the constant cat-and-mouse game between browser developers and exploit writers. A few questioned the real-world impact of these vulnerabilities given Ladybird's small market share, but others argued that finding and fixing these bugs is crucial regardless of current popularity, especially as it may grow. The author's transparency and willingness to engage with commenters were also commended.

  The Hacker News post titled "Pwning the Ladybird Browser" (https://news.ycombinator.com/item?id=43852096) has generated several comments discussing the linked blog post about exploiting vulnerabilities in the Ladybird JavaScript engine, LibJS.

  Several commenters focus on the security implications of using a relatively new and potentially less-tested JavaScript engine like LibJS. One commenter highlights the inherent risk of using a brand-new JavaScript engine, emphasizing that despite the best intentions, unknown vulnerabilities are more likely to exist in newer projects. They also pointed out the potential danger of using such an engine in a browser, as opposed to a controlled environment like a server, where exploitation could have more severe consequences for the user.

  Another commenter questions the choice of using a new engine like LibJS in a browser explicitly aiming for increased security, like Ladybird. They express the view that relying on a less mature JavaScript engine might contradict the browser's primary goal of enhanced security.

  There's discussion surrounding the specific vulnerability exploited in the blog post, with commenters delving into the technical details. One comment elaborates on the nature of the vulnerability, a use-after-free bug, and how it could be exploited to achieve remote code execution.

  A few comments discuss the tradeoffs between security and performance, suggesting that the pursuit of performance optimizations might sometimes inadvertently introduce security flaws. One commenter notes the tendency to prioritize speed improvements, which can lead to overlooking potential security vulnerabilities.

  The potential for supply chain attacks is also raised. One commenter brings up the possibility that an attacker could introduce malicious code into the LibJS project, leading to a compromise of the Ladybird browser even in the absence of direct vulnerabilities.

  Some comments praise the blog post author for responsibly disclosing the vulnerability, acknowledging the importance of ethical hacking in improving software security.

  Finally, a few commenters express interest in the Ladybird browser itself, appreciating its focus on speed and simplicity. They acknowledge the reported vulnerability but remain optimistic about the browser's potential, hoping that the identified issue will be addressed effectively.

• Garak, LLM Vulnerability Scanner

  permalink

  Posted: 2024-11-17 11:37:45

  Verbose tl;dr

  Garak is an open-source tool developed by NVIDIA for identifying vulnerabilities in large language models (LLMs). It probes LLMs with a diverse range of prompts designed to elicit problematic behaviors, such as generating harmful content, leaking private information, or being easily jailbroken. These prompts cover various attack categories like prompt injection, data poisoning, and bias detection. Garak aims to help developers understand and mitigate these risks, ultimately making LLMs safer and more robust. It provides a framework for automated testing and evaluation, allowing researchers and developers to proactively assess LLM security and identify potential weaknesses before deployment.

  NVIDIA has introduced Garak, a novel open-source tool specifically designed to rigorously assess the security vulnerabilities of Large Language Models (LLMs). Garak operates by systematically generating a diverse and extensive array of adversarial prompts, meticulously crafted to exploit potential weaknesses within these models. These prompts are then fed into the target LLM, and the resulting output is meticulously analyzed for a range of problematic behaviors.

  Garak's focus extends beyond simple prompt injection attacks. It aims to uncover a broad spectrum of vulnerabilities, including but not limited to jailbreaking (circumventing safety guidelines), prompt leaking (inadvertently revealing sensitive information from the training data), and generating biased or harmful content. The tool facilitates a deeper understanding of the security landscape of LLMs by providing researchers and developers with a robust framework for identifying and mitigating these risks.

  Garak's architecture emphasizes flexibility and extensibility. It employs a modular design that allows users to easily integrate custom prompt generation strategies, vulnerability detectors, and output analyzers. This modularity allows researchers to tailor Garak to their specific needs and investigate specific types of vulnerabilities. The tool also incorporates various pre-built modules and templates, providing a readily available starting point for evaluating LLMs. This includes a collection of known adversarial prompts and detectors for common vulnerabilities, simplifying the initial setup and usage of the tool.

  Furthermore, Garak offers robust reporting capabilities, providing detailed logs and summaries of the testing process. This documentation helps in understanding the identified vulnerabilities, the prompts that triggered them, and the LLM's responses. This comprehensive reporting aids in the analysis and interpretation of the test results, enabling more effective remediation efforts. By offering a systematic and thorough approach to LLM vulnerability scanning, Garak empowers developers to build more secure and robust language models. It represents a significant step towards strengthening the security posture of LLMs in the face of increasingly sophisticated adversarial attacks.

  • LLM
  • Large Language Model
  • Vulnerability Scanner
  • Security
  • AI Safety
  • AI Security
  • Red Teaming
  • Prompt Injection
  • Jailbreaking
  • Security Testing
  • Nvidia
  • Garak
  • Open Source
  • Tooling
  • machine learning
  • artificial intelligence
  • Jailbreak
  • Adversarial Attacks
  • Security Tool
  • Code Security
  • LLM Security
  • Prompt Engineering
  • Cybersecurity
  • AI Red Teaming
  • LLM Attack
  • LLM Defense
  • Python
  • Framework
  • fuzzing
  • Robustness

  Summary of Comments ( 62 )
  https://news.ycombinator.com/item?id=42163591

  Verbose tl;dr

  Hacker News commenters discuss Garak's potential usefulness while acknowledging its limitations. Some express skepticism about the effectiveness of LLMs scanning other LLMs for vulnerabilities, citing the inherent difficulty in defining and detecting such issues. Others see value in Garak as a tool for identifying potential problems, especially in specific domains like prompt injection. The limited scope of the current version is noted, with users hoping for future expansion to cover more vulnerabilities and models. Several commenters highlight the rapid pace of development in this space, suggesting Garak represents an early but important step towards more robust LLM security. The "arms race" analogy between developing secure LLMs and finding vulnerabilities is also mentioned.

  The Hacker News post for "Garak, LLM Vulnerability Scanner" sparked a fairly active discussion with a variety of viewpoints on the tool and its implications.

  Several commenters expressed skepticism about the practical usefulness of Garak, particularly in its current early stage. One commenter questioned whether the provided examples of vulnerabilities were truly exploitable, suggesting they were more akin to "jailbreaks" that rely on clever prompting rather than representing genuine security risks. They argued that focusing on such prompts distracts from real vulnerabilities, like data leakage or biased outputs. This sentiment was echoed by another commenter who emphasized that the primary concern with LLMs isn't malicious code execution but rather undesirable outputs like harmful content. They suggested current efforts are akin to "penetration testing a calculator" and miss the larger point of LLM safety.

  Others discussed the broader context of LLM security. One commenter highlighted the challenge of defining "vulnerability" in the context of LLMs, as it differs significantly from traditional software. They suggested the focus should be on aligning LLM behavior with human values and intentions, rather than solely on preventing specific prompt injections. Another discussion thread explored the analogy between LLMs and social engineering, with one commenter arguing that LLMs are inherently susceptible to manipulation due to their reliance on statistical patterns, making robust defense against prompt injection difficult.

  Some commenters focused on the technical aspects of Garak and LLM vulnerabilities. One suggested incorporating techniques from fuzzing and symbolic execution to improve the tool's ability to discover vulnerabilities. Another discussed the difficulty of distinguishing between genuine vulnerabilities and intentional features, using the example of asking an LLM to generate offensive content.

  There was also some discussion about the potential misuse of tools like Garak. One commenter expressed concern that publicly releasing such a tool could enable malicious actors to exploit LLMs more easily. Another countered this by arguing that open-sourcing security tools allows for faster identification and patching of vulnerabilities.

  Finally, a few commenters offered more practical suggestions. One suggested using Garak to create a "robustness score" for LLMs, which could help users choose models that are less susceptible to manipulation. Another pointed out the potential use of Garak in red teaming exercises.

  In summary, the comments reflected a wide range of opinions and perspectives on Garak and LLM security, from skepticism about the tool's practical value to discussions of broader ethical and technical challenges. The most compelling comments highlighted the difficulty of defining and addressing LLM vulnerabilities, the need for a shift in focus from prompt injection to broader alignment concerns, and the potential benefits and risks of open-sourcing LLM security tools.

• Fuzzing the PHP Interpreter via Dataflow Fusion

  permalink

  Posted: 2024-11-15 15:36:53

  Verbose tl;dr

  This paper introduces a new fuzzing technique called Dataflow Fusion (DFusion) specifically designed for complex interpreters like PHP. DFusion addresses the challenge of efficiently exploring deep execution paths within interpreters by strategically combining coverage-guided fuzzing with taint analysis. It identifies critical dataflow paths and generates inputs that maximize the exploration of these paths, leading to the discovery of more bugs. The researchers evaluated DFusion against existing PHP fuzzers and demonstrated its effectiveness in uncovering previously unknown vulnerabilities, including crashes and memory safety issues, within the PHP interpreter. Their results highlight the potential of DFusion for improving the security and reliability of interpreted languages.

  The research paper "Fuzzing the PHP Interpreter via Dataflow Fusion" introduces a novel fuzzing technique specifically designed for complex interpreters like PHP. The authors argue that existing fuzzing methods often struggle with these interpreters due to their intricate internal structures and dynamic behaviors. They propose a new approach called Dataflow Fusion, which aims to enhance the effectiveness of fuzzing by strategically combining different dataflow analysis techniques.

  Traditional fuzzing relies heavily on code coverage, attempting to explore as many different execution paths as possible. However, in complex interpreters, achieving high coverage can be challenging and doesn't necessarily correlate with uncovering deep bugs. Dataflow Fusion tackles this limitation by moving beyond simple code coverage and focusing on the flow of data within the interpreter.

  The core idea behind Dataflow Fusion is to leverage multiple dataflow analyses, specifically taint analysis and control-flow analysis, and fuse their results to guide the fuzzing process more intelligently. Taint analysis tracks the propagation of user-supplied input through the interpreter, identifying potential vulnerabilities where untrusted data influences critical operations. Control-flow analysis, on the other hand, maps out the possible execution paths within the interpreter. By combining these two analyses, Dataflow Fusion can identify specific areas of the interpreter's code where tainted data affects control flow, thus pinpointing potentially vulnerable locations.

  The paper details the implementation of Dataflow Fusion within a custom fuzzer for the PHP interpreter. This fuzzer uses a hybrid approach, combining both mutation-based fuzzing, which modifies existing inputs, and generation-based fuzzing, which creates entirely new inputs. The fuzzer is guided by the Dataflow Fusion engine, which prioritizes inputs that are likely to explore interesting and potentially vulnerable paths within the interpreter.

  The authors evaluate the effectiveness of their approach by comparing it to existing fuzzing techniques. Their experiments demonstrate that Dataflow Fusion significantly outperforms traditional fuzzing methods in terms of bug discovery. They report uncovering a number of previously unknown vulnerabilities in the PHP interpreter, including several critical security flaws. These findings highlight the potential of Dataflow Fusion to improve the security of complex interpreters.

  Furthermore, the paper discusses the challenges and limitations of the proposed approach. Dataflow analysis can be computationally expensive, particularly for large and complex interpreters. The authors address this issue by employing various optimization techniques to improve the performance of the Dataflow Fusion engine. They also acknowledge that Dataflow Fusion, like any fuzzing technique, is not a silver bullet and may not be able to uncover all vulnerabilities. However, their results suggest that it represents a significant step forward in the ongoing effort to improve the security of complex software systems. The paper concludes by suggesting future research directions, including exploring the applicability of Dataflow Fusion to other interpreters and programming languages.

  • fuzzing
  • php
  • interpreter
  • dataflow analysis
  • data flow fusion
  • Security Testing
  • software testing
  • vulnerability discovery
  • program analysis
  • compiler optimization
  • dynamic analysis
  • dataflow fusion
  • Security

  Summary of Comments ( 3 )
  https://news.ycombinator.com/item?id=42147833

  Verbose tl;dr

  Hacker News users discussed the potential impact and novelty of the PHP fuzzer described in the linked paper. Several commenters expressed skepticism about the significance of the discovered vulnerabilities, pointing out that many seemed related to edge cases or functionalities rarely used in real-world PHP applications. Others questioned the fuzzer's ability to uncover truly impactful bugs compared to existing methods. Some discussion revolved around the technical details of the fuzzing technique, "dataflow fusion," with users inquiring about its specific advantages and limitations. There was also debate about the general state of PHP security and whether this research represents a meaningful advancement in securing the language.

  The Hacker News post titled "Fuzzing the PHP Interpreter via Dataflow Fusion" (https://news.ycombinator.com/item?id=42147833) has several comments discussing the linked research paper. The discussion revolves around the effectiveness and novelty of the presented fuzzing technique.

  One commenter highlights the impressive nature of finding 189 unique bugs, especially considering PHP's maturity and the extensive testing it already undergoes. They point out the difficulty of fuzzing interpreters in general and praise the researchers' approach.

  Another commenter questions the significance of the found bugs, wondering how many are exploitable and pose a real security risk. They acknowledge the value of finding any bugs but emphasize the importance of distinguishing between minor issues and serious vulnerabilities. This comment sparks a discussion about the nature of fuzzing, with replies explaining that fuzzing often reveals unexpected edge cases and vulnerabilities that traditional testing might miss. It's also mentioned that while not all bugs found through fuzzing are immediately exploitable, they can still provide valuable insights into potential weaknesses and contribute to the overall robustness of the software.

  The discussion also touches on the technical details of the "dataflow fusion" technique used in the research. One commenter asks for clarification on how this approach differs from traditional fuzzing methods, prompting a response explaining the innovative aspects of combining dataflow analysis with fuzzing. This fusion allows for more targeted and efficient exploration of the interpreter's state space, leading to a higher likelihood of uncovering bugs.

  Furthermore, a commenter with experience in PHP internals shares insights into the challenges of maintaining and debugging such a complex codebase. They appreciate the research for contributing to the improvement of PHP's stability and security.

  Finally, there's a brief exchange about the practical implications of these findings, with commenters speculating about potential patches and updates to the PHP interpreter based on the discovered vulnerabilities.

  Overall, the comments reflect a positive reception of the research, acknowledging the challenges of fuzzing interpreters and praising the researchers' innovative approach and the significant number of bugs discovered. There's also a healthy discussion about the practical implications of the findings and the importance of distinguishing between minor bugs and serious security vulnerabilities.