diff options
Diffstat (limited to 'documentation/slides-final/slides.md')
| -rw-r--r-- | documentation/slides-final/slides.md | 253 |
1 files changed, 253 insertions, 0 deletions
diff --git a/documentation/slides-final/slides.md b/documentation/slides-final/slides.md new file mode 100644 index 0000000..54b1fa8 --- /dev/null +++ b/documentation/slides-final/slides.md @@ -0,0 +1,253 @@ +title: STLDoctor +output: index.html +controls: false + +-- + +<style> + +.footnote { + font-size: 16pt; + position: absolute; + color: gray; + bottom: 0px; + right: 0px; +} + +.slide-content { + position: relative; +} + +.slide-content > ul >li { + padding: 7px 0px; +} + +.slide-content > p > img { + width: 100%; +} + +</style> + +-- + +<!-- Recap of the service and the problems I +encountered preparing for the CTF and during the CTF --> + +# STLDoctor 💉 + +-- + +### Index 🗄️ + +- Service recap +- Optimization +- ENOWARS 5 +- Reflection + +-- + +### Refreshing Memories 💾 + +- Plaintext service written in C +- Users upload STL files for parsing +- Private and public storage (2 flagstores) +- 1. Vuln: Deserialization +- 2. Vuln: Hash preimage + +<img style="width:300px !important; height:240px; position:absolute; bottom:80px; right:70px;" src="media/stldoc.png"> + +-- + +### Since Last Meeting ⏩ + +<!-- Of these three, we want to take a closer look +at the performance improvements necessary --> + +- Performance improvements +- Added service fluff + +<img id=img1 src="media/stl1.png"> +<img id=img2 src="media/stl2.png"> +<img id=img3 src="media/stl3.png"> + +<style> + #img1 { + position: absolute; + left: 2.5%; + bottom: 7%; + width: 30%; + } + #img2 { + position: absolute; + left: 35%; + bottom: 7%; + width: 30%; + } + #img3 { + position: absolute; + left: 67.5%; + bottom: 7%; + width: 30%; + } +</style> + +-- + +### Issues 😒 + +<!-- since there were some slow io operations and +either memory leak issues with pwnlib (witout patch) +or engine request issues with the patch, +sooo I decided to refactor to use enochecker3 for asyncio + +also noticed that I was checking the same thing multiple times +in the checker, so tried to condense functionality --> + +- Slow search / list operations +- Enochecker memory leak without patch +- Engine error on worker restart with patch +- Logs not showing up in ELK + +-- + +### Solutions 💡 + +- Index files with locks for directory listing +- Refactored checker for asyncio +- Condensed checker functionality +- Increase docker-compose log size + +-- + +# ENOWARS 5 + +-- + +### OSError 💢 + +- Checker throws `INTERNAL_ERROR` on bad connection +- Fixed in c97789ad.. of enochecker3 + +<img style="" src="media/stldoc_dead_offline.png"> + +-- + +### Checker Overload 💥 + +<!-- all of a sudden all checker tasks are being aborted. +Since all tasks were aborted, all workers must be affected +and a blockage of a single worker could not have been the +cause.. +During the ctf we found the checker at high load.. +Suspected that OFFLINE/unresponsive teams could be slowing +down the service since then the timeouts are too large and the +queue couldnt be emptied fast enough --> + +- Checker tasks being aborted for every team + +<img style="height: 80%" src="media/stldoc_dead_r432.png"> + +-- + +### Checker Overload 💥 + +<!-- MEME CREDIT: Liikt --> +<img style="height: 80%" src="media/stldoc_dead.png"> + +-- + +### Anomaly 👽 + +<!-- service didnt timeout except on vulnboxes where everything +seemed to be running weirdly, so unsure how to debug --> + +<img style="" src="media/enowars5-timeout.png"> + +-- + +### Feedback 🤔 + +- 1. flagstore exploited after ~4h (R190) +- 2. flagstore not exploited + +<!-- MEME CREDIT: [KuK] cluosh --> +<img style="position:absolute; right:0px; height:300px; width:450px" src="media/player-meme-struggling.png"> +<img style="position:absolute; left:0px; height:300px; width: 400px;" src="media/player-meme-hashfunc.png"> + +-- + +### Conclusion 🎉 + +- Relatively good uptime +- Not too easy / hard +- Users found vulns interesting +- No (known) unintended vuln +- Had a lot of fun + +-- + +-- + +### Slow IO 🐌 + +<!-- Noticed that running 'ls' on the service upload directory +takes very long +implementation in e.g. glibc actually pretty sane (see end slides) +but bad cache performance / buffer not used / docker overlay fs --> + +- Enumerating files in a directory is expensive +- Index file per directory containing file names +- File locks to ensure exclusive writes + +<img style="position:absolute; bottom: 30%; left:10%; width: 70% !important;" src="media/dirlist.png"> + +-- + +### Investigating `readdir(..)` 🔍 + +<!-- What makes readdir slow? actually looks like a sane implementation. +We buffer an amount of entries and rebuffer when we run out. +My guess is that we can buffer more with a regular file (also we have the choice). +Better cache performance? +Although the read is from one location, is probably just an abstraction +Source: GLIBC 2.0.2--> + +`__readdir(..)`: + +<img style="" src="media/readdir.png"> + +-- + +### Investigating `readdir(..)` 🔍 + +`__get_dir_entries(..)`: + +<img style="" src="media/getdirentries.png"> + +-- + +### Checker Overload + +<img style="" src="media/stldoc_dead_r17.png"> + +-- + +### Checker Overload + +<img style="" src="media/stldoc_dead_r469.png"> + +-- + + + + + +<script> + // var slide_headers = document.querySelectorAll(".slide-content > h3"); + // for (var i = 0; i < slide_headers.length; i++) { + // var img = document.createElement('img') + // img.src = "logo.png"; + // img.style = "height: 2.4ex; padding-right: 10px; float:right"; + // slide_headers[i].append(img); + // } +</script> |