Today's Securly Bypass Flavor
Got a new one, not as sophisticated but interesting: github.com/ading2210/secular-ly/tree/main
Essentially, this uses a file on a machine, Java, and potentially Bookmark creations to create a state in which Securly can be overridden. The code is public so you can see how it works. It's pretty straightforward. We have already submitted a ticket to Securly. I would advise others to do the same.
To protect/prevent:
1. Users & Browsers Setting: URL Blocking --> for the domains listed in the GIT. Blacklist them where applicable (GAdmin, Firewall, etc). GIT should also just be blocked for students period IMO unless overrides needed for specific items. Note the .dev and .app pages can jump / move, domain names are just that so...this could be a moving target / whack-a-mole
2. Users & Browsers Setting: URL Blocking --> Block file://* inside your URL blocklist for students. Prevents user from accessing local files on the Chromebook with the Chrome browser. This is somewhat of a nuclear option here but it works to prevent local hosted .html files
3. Users & Browsers Setting: Content/Javascript --> Disable Javascript or at least on specific sites (local files, websites, etc). Prevent the user from engaging with Javascript to run functions in a webpage. If Java is enabled this then uses the cookies created with Securly to then break the extension as it runs inside the Chrome browser.
Have fun fellow K12 folks. This won't be the last time we discuss this but...this is today's fun one of the day.
6 points
Running Linux Inside a PDF: linuxpdf
You open a PDF in your browser, there's a terminal inside, and you can run commands.
Adobe's spec supports JavaScript execution.
If the viewer implements it, JS code embedded in a PDF can run.
So a PDF isn't just a document; it can actually be used as a runtime environment too.
This feature has been actively used in PDF-based attacks for years.
linuxpdf exploits exactly this.
Ading2210 compiled the Linux kernel to WebAssembly using Emscripten.
The resulting WASM binary is embedded inside the PDF.
When the PDF opens, the JavaScript engine runs this WASM and you see a terminal.
ls, cat, echo
Commands like these work.
A real shell experience.
Of course, it has its limitations too. Not every PDF viewer can open it because not all of them support JS execution.
Chrome's built-in viewer behaves in an isolated way and its WASM support isn't complete.
Chromium or Firefox is recommended for the demo.
There's also the performance issue. Every keystroke goes through the WASM runtime, so it can't be as fast as a real terminal.
From a security perspective, what the project demonstrates matters.
PDFs being able to run JavaScript is an old risk, but once it reaches the level of "a full operating system can run inside this", it looks different, of course.
In practice, it can be a good reference point for thinking about how sophisticated a malicious PDF can get.
!Linux terminal running inside a PDF
The project's source code is available on GitHub. The demo PDF opens in the browser without downloading.
Source:
https://github.com/ading2210/linuxpdf
Demo:
https://linux.doompdf.dev/
---
Originally written in Turkish on eminuzun.com. AI was used only for the translation.
Mentions
Today's Securly Bypass Flavor Got a new one, not as sophisticated but interesting: github.com/ading2210/secular-ly/tree/main Essentially, this uses a file on a machine, Java, and potentially Bookmark creations to create a state in which Securly can be overridden. The code is public so you can see how it works. It's pretty straightforward. We have already submitted a ticket to Securly. I would advise others to do the same. To protect/prevent: 1. Users & Browsers Setting: URL Blocking --> for the domains listed in the GIT. Blacklist them where applicable (GAdmin, Firewall, etc). GIT should also just be blocked for students period IMO unless overrides needed for specific items. Note the .dev and .app pages can jump / move, domain names are just that so...this could be a moving target / whack-a-mole 2. Users & Browsers Setting: URL Blocking --> Block file://* inside your URL blocklist for students. Prevents user from accessing local files on the Chromebook with the Chrome browser. This is somewhat of a nuclear option here but it works to prevent local hosted .html files 3. Users & Browsers Setting: Content/Javascript --> Disable Javascript or at least on specific sites (local files, websites, etc). Prevent the user from engaging with Javascript to run functions in a webpage. If Java is enabled this then uses the cookies created with Securly to then break the extension as it runs inside the Chrome browser. Have fun fellow K12 folks. This won't be the last time we discuss this but...this is today's fun one of the day.
You can run Linux in a PDF: ading2210/linuxpdf
Running Linux Inside a PDF: linuxpdf You open a PDF in your browser, there's a terminal inside, and you can run commands. Adobe's spec supports JavaScript execution. If the viewer implements it, JS code embedded in a PDF can run. So a PDF isn't just a document; it can actually be used as a runtime environment too. This feature has been actively used in PDF-based attacks for years. linuxpdf exploits exactly this. Ading2210 compiled the Linux kernel to WebAssembly using Emscripten. The resulting WASM binary is embedded inside the PDF. When the PDF opens, the JavaScript engine runs this WASM and you see a terminal. ls, cat, echo Commands like these work. A real shell experience. Of course, it has its limitations too. Not every PDF viewer can open it because not all of them support JS execution. Chrome's built-in viewer behaves in an isolated way and its WASM support isn't complete. Chromium or Firefox is recommended for the demo. There's also the performance issue. Every keystroke goes through the WASM runtime, so it can't be as fast as a real terminal. From a security perspective, what the project demonstrates matters. PDFs being able to run JavaScript is an old risk, but once it reaches the level of "a full operating system can run inside this", it looks different, of course. In practice, it can be a good reference point for thinking about how sophisticated a malicious PDF can get. !Linux terminal running inside a PDF The project's source code is available on GitHub. The demo PDF opens in the browser without downloading. Source: https://github.com/ading2210/linuxpdf Demo: https://linux.doompdf.dev/ --- Originally written in Turkish on eminuzun.com. AI was used only for the translation.