[
https://issues.apache.org/jira/browse/CALCITE-7436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vishal Satish updated CALCITE-7436:
-----------------------------------
Description:
[PR Link|https://github.com/apache/calcite-avatica/pull/300]
Right now, the OSS-Fuzz setup for Avatica barely touches any of the important
parts. I've checked the coverage on the core module and it is is basically zero
because it only exercises a few peripheral helper classes.
But by adding four proper "deep" fuzz targets using Jazzer (the libFuzzer-style
fuzzer that works great with JVM projects). These targets will live right
inside the calcite-avatica module and are designed to fuzz the parts that
actually matter for stability and security.{_}The new fuzzers covers the
following{_}
* *JsonHandlerFuzzer* → stresses the full round-trip JSON serialization +
deserialization of requests and responses (via Jackson)
* *ProtobufHandlerFuzzer* → checks binary parsing + POJO mapping for the
Protobuf path — making sure nothing breaks when translating between wire format
and Java objects
* *TypedValueFuzzer* → goes after the TypedValue factory and all the JDBC type
conversions — especially fun things like numeric overflows, weird edge values,
etc.
* *AvaticaSiteFuzzer* → uses dynamic proxies to exercise the JDBC-to-Java type
translation logic across 15+ different SQL/JDBC types
*
*Base64Fuzzer:* Protocol utility testing
* *ConnectStringParserFuzzer:* JDBC connection string parsing
These are built to run on google's oss fuzz infrastructure, and if this issue
gets rectified, we can push a pr to the google oss fuzz repo as well.
For now i have raised a pr in the calcita avatica repo : [PR Link|
We've added a 'cifuzz.yml' GitHub Action to run these targets on every PR.
These will pass once the Google OSS-Fuzz configuration is updated to reference
this upstream source.
[https://github.com/apache/calcite-avatica/pull/300] ]
The main things we're hoping to find and maybe we can fix as well.
* Out-of-memory crashes or crazy CPU usage
* Sneaky unchecked exceptions (BufferUnderflowException, etc.)
* Subtle bugs in how data gets translated between formats
For local development, anyone can run these fuzzers quickly using the Jazzer
CLI or the Maven plugin(Note: we've kept them out of regular JUnit CI on
purpose as they're non-deterministic and eat a lot of CPU, so they're better
suited for dedicated fuzzing environments.)
Overall the fuzzers hit thousands of lines of code and it will significantly
increase coverage of the fuzzers.
was:
[PR Link|https://github.com/apache/calcite-avatica/pull/300]
Right now, the OSS-Fuzz setup for Avatica barely touches any of the important
parts. I've checked the coverage on the core module and it is is basically zero
because it only exercises a few peripheral helper classes.
But by adding four proper "deep" fuzz targets using Jazzer (the libFuzzer-style
fuzzer that works great with JVM projects). These targets will live right
inside the calcite-avatica module and are designed to fuzz the parts that
actually matter for stability and security.{_}The new fuzzers covers the
following{_}
* *JsonHandlerFuzzer* → stresses the full round-trip JSON serialization +
deserialization of requests and responses (via Jackson)
* *ProtobufHandlerFuzzer* → checks binary parsing + POJO mapping for the
Protobuf path — making sure nothing breaks when translating between wire format
and Java objects
* *TypedValueFuzzer* → goes after the TypedValue factory and all the JDBC type
conversions — especially fun things like numeric overflows, weird edge values,
etc.
* *AvaticaSiteFuzzer* → uses dynamic proxies to exercise the JDBC-to-Java type
translation logic across 15+ different SQL/JDBC types
These are built to run on google's oss fuzz infrastructure, and if this issue
gets rectified, we can push a pr to the google oss fuzz repo as well.
For now i have raised a pr in the calcita avatica repo : [PR Link|
[https://github.com/apache/calcite-avatica/pull/300] ]
The main things we're hoping to find and maybe we can fix as well.
* Out-of-memory crashes or crazy CPU usage
* Sneaky unchecked exceptions (BufferUnderflowException, etc.)
* Subtle bugs in how data gets translated between formats
For local development, anyone can run these fuzzers quickly using the Jazzer
CLI or the Maven plugin(Note: we've kept them out of regular JUnit CI on
purpose as they're non-deterministic and eat a lot of CPU, so they're better
suited for dedicated fuzzing environments.)
Overall the fuzzers hit thousands of lines of code and it will significantly
increase coverage of the fuzzers.
> Add high-coverage Jazzer fuzzing for Avatica core modules
> ---------------------------------------------------------
>
> Key: CALCITE-7436
> URL: https://issues.apache.org/jira/browse/CALCITE-7436
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
> Reporter: Vishal Satish
> Assignee: Vishal Satish
> Priority: Major
> Labels: pull-request-available
>
> [PR Link|https://github.com/apache/calcite-avatica/pull/300]
> Right now, the OSS-Fuzz setup for Avatica barely touches any of the important
> parts. I've checked the coverage on the core module and it is is basically
> zero because it only exercises a few peripheral helper classes.
> But by adding four proper "deep" fuzz targets using Jazzer (the
> libFuzzer-style fuzzer that works great with JVM projects). These targets
> will live right inside the calcite-avatica module and are designed to fuzz
> the parts that actually matter for stability and security.{_}The new fuzzers
> covers the following{_}
> * *JsonHandlerFuzzer* → stresses the full round-trip JSON serialization +
> deserialization of requests and responses (via Jackson)
> * *ProtobufHandlerFuzzer* → checks binary parsing + POJO mapping for the
> Protobuf path — making sure nothing breaks when translating between wire
> format and Java objects
> * *TypedValueFuzzer* → goes after the TypedValue factory and all the JDBC
> type conversions — especially fun things like numeric overflows, weird edge
> values, etc.
> * *AvaticaSiteFuzzer* → uses dynamic proxies to exercise the JDBC-to-Java
> type translation logic across 15+ different SQL/JDBC types
> *
> *Base64Fuzzer:* Protocol utility testing
> * *ConnectStringParserFuzzer:* JDBC connection string parsing
> These are built to run on google's oss fuzz infrastructure, and if this issue
> gets rectified, we can push a pr to the google oss fuzz repo as well.
> For now i have raised a pr in the calcita avatica repo : [PR Link|
> We've added a 'cifuzz.yml' GitHub Action to run these targets on every PR.
> These will pass once the Google OSS-Fuzz configuration is updated to
> reference this upstream source.
> [https://github.com/apache/calcite-avatica/pull/300] ]
> The main things we're hoping to find and maybe we can fix as well.
> * Out-of-memory crashes or crazy CPU usage
> * Sneaky unchecked exceptions (BufferUnderflowException, etc.)
> * Subtle bugs in how data gets translated between formats
> For local development, anyone can run these fuzzers quickly using the Jazzer
> CLI or the Maven plugin(Note: we've kept them out of regular JUnit CI on
> purpose as they're non-deterministic and eat a lot of CPU, so they're better
> suited for dedicated fuzzing environments.)
> Overall the fuzzers hit thousands of lines of code and it will significantly
> increase coverage of the fuzzers.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
