Skip to content

#HITB2021SIN HATS D1 - Post Talk Q&A With Xingyu Jin & Richard Neal

Xingyu JinRichard Neal

interviewCommunityHack In The Box Security Conference13 minAdvancedOpen on YouTube ↗

Presenters detail vulnerability discovery and exploitation in #HITB2021SIN HATS D1 - Post Talk Q&A With Xingyu Jin & Richard Neal.

Summary

### Overview This session is a post-talk Q&A from HITB2021SIN featuring security researchers Xingyu Jin and Richard Neal. The discussion covers practical aspects of vulnerability disclosure, Android platform defense strategies, the handling of bug bounty submissions lacking proofs of concept (PoCs), Google's fuzzing and crash triage workflows, and recruitment within security teams.

### Key Topics - **External Vulnerability Submissions**: Handling vulnerability reports submitted without detailed write-ups or functional proofs of concept, and how bug bounty programs incentivize complete submissions. - **Android Security Architecture & Defensive Mechanisms**: Initiatives such as the Generic Kernel Image (GKI) project designed to streamline kernel security patching across the diverse device ecosystem. - **Memory Safety and Language Adoption**: Transitioning components from C to Rust across internal teams, applications, and potentially kernel development to curb memory corruption vulnerabilities. - **Fuzzing Infrastructure & Crash Triage**: Methodologies for fuzzing on virtualized and physical devices across Android and Chrome, along with distributed workflows for evaluating crash exploitability. - **Public Disclosure Philosophy**: The rationale for disclosing vulnerability details publicly to empower defensive security rather than leaving security in closed silos.

### Technical Details - **Vulnerability Reports Without PoCs**: The speakers estimate that approximately 20% to 30% of vulnerability reports arrive without a proof of concept or reproduction steps. While experienced and frequent researchers usually include comprehensive reproduction materials, newer contributors sometimes supply minimal information (such as pointing out a few lines of code), requiring internal engineers to verify and construct exploit chains themselves. - **Generic Kernel Image (GKI)**: Addressed as a central effort to unify the kernel baseline across Android devices. Centrally delivering a single kernel image reduces the per-tree maintenance burden for upstream security patches, allowing downstream devices to receive security updates much faster. - **Language Transition to Rust**: Acknowledging that the Linux kernel remains predominantly written in C, internal teams are increasingly adopting Rust for applications and exploring it for kernel development to directly eliminate common memory safety issues, undefined memory accesses, and race conditions. - **Fuzzing and Hardware Heterogeneity**: Android fuzzing utilizes both virtualized environments and physical hardware. A primary technical challenge in fuzzing Android devices stems from the high number of OEM-specific hardware drivers, where standard virtualization often fails. Fuzzing outputs and crash triage are not managed by a single monolithic team; instead, initial triage routes crashes to the relevant subsystem groups (such as Chrome, Android, or specific development teams responsible for the code).

### Takeaways - Fuzzing and automated static/dynamic analysis must be paired with human code review, as complex bugs and non-standard driver layers often evade standard virtualization. - Mitigating memory corruption requires systemic architectural adjustments, including memory-safe languages like Rust and centralized patching pipelines like GKI. - Public disclosure of security research and vulnerability findings is viewed by the researchers as essential for fostering stronger overall community defense against malicious exploitation.

Related talks