Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Po-Ning Tseng

dblp:168/8683 · DBLP profile ↗
← Back
2ranked-venue papers
0as first author
0since 2021 · last 2019
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Computer networks · 1Security and privacy · 1

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Network and information security
2 papers
Systems and software security · 51% Network security · 44% Cryptographic protocols and secure computation · 4%
Software engineering, system software, and programming languages
1 paper
Operating systems · 77% Software testing · 23%

Topics — the 8 heaviest of 10, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Systems and software security › vulnerability discovery › fuzzing
kernel fuzzing
0.412019
Fuzzing File Systems via Two-Dimensional Input Space Exploration · IEEE Symposium on Security and Privacy 2019
Systems and software security
vulnerability discovery
0.412019
Fuzzing File Systems via Two-Dimensional Input Space Exploration · IEEE Symposium on Security and Privacy 2019
Operating systems › resource management › storage management
file systems
0.412019
Fuzzing File Systems via Two-Dimensional Input Space Exploration · IEEE Symposium on Security and Privacy 2019
Operating systems › resource management › storage management › file systems
file system bug detection
0.412019
Fuzzing File Systems via Two-Dimensional Input Space Exploration · IEEE Symposium on Security and Privacy 2019
Network security › attack resilience › attack mitigation › denial-of-service defense
DDoS defense
0.212015
A Practical System for Guaranteed Access in the Presence of DDoS Attacks and Flash Crowds · ICNP 2015
Network security › attack strategy
denial-of-service attack
0.212015
A Practical System for Guaranteed Access in the Presence of DDoS Attacks and Flash Crowds · ICNP 2015
Software testing › fuzzing
feedback-guided fuzzing
0.112019
Fuzzing File Systems via Two-Dimensional Input Space Exploration · IEEE Symposium on Security and Privacy 2019
Software testing
fuzzing
0.112019
Fuzzing File Systems via Two-Dimensional Input Space Exploration · IEEE Symposium on Security and Privacy 2019

Methods — techniques the papers use, named apart from their topics

library OS · 0.8coverage-guided fuzzing · 0.8simulation · 0.2cryptographic token · 0.2
YearPublicationVenuePosition
2019 Fuzzing File Systems via Two-Dimensional Input Space Exploration
abstract
File systems, a basic building block of an OS, are too big and too complex to be bug free. Nevertheless, file systems rely on regular stress-testing tools and formal checkers to find bugs, which are limited due to the ever-increasing complexity of both file systems and OSes. Thus, fuzzing, proven to be an effective and a practical approach, becomes a preferable choice, as it does not need much knowledge about a target. However, three main challenges exist in fuzzing file systems: mutating a large image blob that degrades overall performance, generating image-dependent file operations, and reproducing found bugs, which is difficult for existing OS fuzzers. Hence, we present JANUS, the first feedback-driven fuzzer that explores the two-dimensional input space of a file system, i.e., mutating metadata on a large image, while emitting image-directed file operations. In addition, JANUS relies on a library OS rather than on traditional VMs for fuzzing, which enables JANUS to load a fresh copy of the OS, thereby leading to better reproducibility of bugs. We evaluate JANUS on eight file systems and found 90 bugs in the upstream Linux kernel, 62 of which have been acknowledged. Forty-three bugs have been fixed with 32 CVEs assigned. In addition, JANUS achieves higher code coverage on all the file systems after fuzzing 12 hours, when compared with the state-of-the-art fuzzer Syzkaller for fuzzing file systems. JANUS visits 4.19x and 2.01x more code paths in Btrfs and ext4, respectively. Moreover, JANUS is able to reproduce 88-100% of the crashes, while Syzkaller fails on all of them.
Wen Xu 0002, Hyungon Moon, Sanidhya Kashyap, Po-Ning Tseng, Taesoo Kim
IEEE Symposium on Security and Privacy4
2015 A Practical System for Guaranteed Access in the Presence of DDoS Attacks and Flash Crowds
abstract
With the growing incidents of flash crowds and sophisticated DDoS attacks mimicking benign traffic, it becomes challenging to protect Internet-based services solely by differentiating attack traffic from legitimate traffic. While fair-sharing schemes are commonly suggested as a defense when differentiation is difficult, they alone may suffer from highly variable or even unbounded waiting times. We propose RainCheck Filter (RCF), a lightweight primitive that guarantees bounded waiting time for clients despite server flooding without keeping per-client state on the server. RCF achieves strong waiting time guarantees by prioritizing clients based on how long the clients have waited - as if the server maintained a queue in which the clients lined up waiting for service. To avoid keeping state for every incoming client request, the server sends to the client a raincheck, a timestamped cryptographic token that not only informs the client to retry later but also serves as a proof of the client's priority level within the virtual queue. We prove that every client complying with RCF can access the server in bounded time, even under a flash crowd incident or a DDoS attack. Our large-scale simulations confirm that RCF provides a small and predictable maximum waiting time while existing schemes cannot. To demonstrate its deployability, we implement RCF as a Python module such that web developers can protect a critical server resource by adding only three lines of code.
Yi-Hsuan Kung, Taeho Lee 0003, Po-Ning Tseng, Hsu-Chun Hsiao, Tiffany Hyun-Jin Kim, Soo Bum Lee, Yue-Hsun Lin, Adrian Perrig
ICNP3