2019
DOI: 10.1109/tdsc.2019.2915829
|View full text |Cite
|
Sign up to set email alerts
|

KALD: Detecting Direct Pointer Disclosure Vulnerabilities

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
1
1

Citation Types

0
2
0

Year Published

2019
2019
2024
2024

Publication Types

Select...
3
1

Relationship

1
3

Authors

Journals

citations
Cited by 4 publications
(2 citation statements)
references
References 18 publications
0
2
0
Order By: Relevance
“…Automated vulnerability repair aims to fix security vulnerabilities automatically without human debugging effort and plays a crucial role in countering emergent security concerns [29], [30] in the security community. The typical workflow of vulnerability repair is usually composed of four steps: (1) the detection phase utilizes vulnerability analysis tools under consideration (e.g., Infer [11] and SpotBugs [31]) to statically analyze source code and indicate a suspicious line containing a vulnerability; (2) the repair phase then generates various new program variants (i.e., candidate patches) by applying a set of transformation rules to these suspicious lines [20]; (3) the verification phase recompiles the vulnerable program with the generated patch to check if it can pass a functional test suite (if such a test suite exists), and then adopts the vulnerability analysis tools (e.g., Infer [11]) to check if the reported vulnerability is fixed; (4) the deployment phase employs security researchers to review and deploy a patch in practice after the patch has been found to pass the test suite and vulnerability analysis tools [32], [33].…”
Section: Automated Vulnerability Repairmentioning
confidence: 99%
“…Automated vulnerability repair aims to fix security vulnerabilities automatically without human debugging effort and plays a crucial role in countering emergent security concerns [29], [30] in the security community. The typical workflow of vulnerability repair is usually composed of four steps: (1) the detection phase utilizes vulnerability analysis tools under consideration (e.g., Infer [11] and SpotBugs [31]) to statically analyze source code and indicate a suspicious line containing a vulnerability; (2) the repair phase then generates various new program variants (i.e., candidate patches) by applying a set of transformation rules to these suspicious lines [20]; (3) the verification phase recompiles the vulnerable program with the generated patch to check if it can pass a functional test suite (if such a test suite exists), and then adopts the vulnerability analysis tools (e.g., Infer [11]) to check if the reported vulnerability is fixed; (4) the deployment phase employs security researchers to review and deploy a patch in practice after the patch has been found to pass the test suite and vulnerability analysis tools [32], [33].…”
Section: Automated Vulnerability Repairmentioning
confidence: 99%
“…To defend against ROP attacks, security researchers proposed address space layout randomization (ASLR), which randomizes the address of code, stack, and heap, making it hard to predict the code gadgets' addresses and the buffer overflowed address. However, ASLR is vulnerable to address leaks [27]. Its design cannot solve the return address corruption problem fundamentally.…”
Section: B Rop and Jop Attacksmentioning
confidence: 99%