On Sat, 12 Jul 2025 19:41:55 -0000 (UTC)
Ray Banana <rayban@raybanana.net> wrote:
* Marco Moock wrote:
On 12.07.2025 10:21 Uhr Anonymous wrote:
Some have claimed that Rocksolid Light is insecure. They have claimed
that there are many vulnerabilities in the codebase. They have
claimed that Rocksolid Light should not be used or peered.
Yet I have not seen a single supposed vulnerability demonstrated.
I have not seen any CVE filings.
Can anyone demonstrate and prove any of the claimed exploits?
It least older versions were vulnerable to SQL injections that made creating files in the spool directory possible. The files.php file also seems vulnerable to such attacks.
That would explain how the "haxxor" was able to grab account data for
a technical account for i2pn2.org (presumably the account used for the communication between the rslight frontend and the i2pn2 backend server).
To make things even worse, there is nobody who is able to revoke
the compromised account or change its password.
--
-f-a|U-e-u-+ rCo -a-a-|-+-+|U
https://www.eternal-september.org
I am poking around the Rocksolid Light codebase. It would take a sizeable amount of work to fix some of the problems, but it is not insurmountable or gargantuan in scope, although there would be some tedium. It looks like the insecurities can be fixed if some of the attack vectors are gutted:
* remove the file upload and storage feature except for MIME attachments
* remove code for sqlite spool and force reversion to tradspool
* replace all sqlite functions with plain text parsing functions with santizers
* replace sqlite overview data with plaintext data store
* sanitize / validate web form inputs on the server side before any data is processed
* reject and don't process articles or control messages with badchars or invalid utf-8
* sanitize / validate nntp session commands more thoroughly
* validate and santize BBS mail messages before passing them to further functions or to inboxes.
* replace php pctnl functions with lower-privileged workarounds
* add code to validate and sanitize badchars from being passed to logs, spamassassin, mail server
* sandbox unencrypted nntp port 119 to localhost, forcing bigworld to use TLS in nntp-ssl.php
* going forward commit to zero use of third-party sql / sqlite libraries, and instead create custom functions using PHP native code, relying on tradspool and text files the old Unix way. A properly organized file tree will work as well as a database, with less overhead, just requiring more code, and the main tradeoff is more complex processing versus simple database commands
* going forward commit to a prefix-sorted tradspool tree instead of database message storage
* have tested Rocksolid Light 'as is' for hundreds of newsgroups and it has managed to perform well so far, and since this application is not meant for serving tens of thousands of newsgroups these changes should have negligible impact on performance efficiency
* after fixing the vulnerability vector bugs, begin stress testing by increasing the number of newsgroups and connected users pulling article data and benchmarking until performance upper limits are hit, then identify the bottle necks and optimize from there
What am I missing so far?
I am poking around the Rocksolid Light codebase. It would take asizeable amount of work to fix some of the problems, but it is not insurmountable or gargantuan in scope, although there would be some
* remove the file upload and storage feature except for MIME attachmentssantizers
* remove code for sqlite spool and force reversion to tradspool
* replace all sqlite functions with plain text parsing functions with
* replace sqlite overview data with plaintext data storedata is processed
* sanitize / validate web form inputs on the server side before any
* reject and don't process articles or control messages with badcharsor invalid utf-8
* sanitize / validate nntp session commands more thoroughlyfurther functions or to inboxes.
* validate and santize BBS mail messages before passing them to
* replace php pctnl functions with lower-privileged workaroundslogs, spamassassin, mail server
* add code to validate and sanitize badchars from being passed to
* sandbox unencrypted nntp port 119 to localhost, forcing bigworld touse TLS in nntp-ssl.php
* going forward commit to zero use of third-party sql / sqlitelibraries, and instead create custom functions using PHP native code,
* going forward commit to a prefix-sorted tradspool tree instead ofdatabase message storage
* have tested Rocksolid Light 'as is' for hundreds of newsgroups andit has managed to perform well so far, and since this application is not
* after fixing the vulnerability vector bugs, begin stress testing byincreasing the number of newsgroups and connected users pulling article
What am I missing so far?
Addendum:root user by checking to SUID / RUID at beginning of every script
* configure all scripts and PHP files to prohibit any invocation as
* prohibit running install scripts as root user, except to requestroot for registering init / systemd service for the sync job / cron job
* add a script to automatically check file permissions, reportdiscrepancies, and correct wrong permissions automatically
* bundle with firejail / jailkit / lxd / chroot options includingnetwork shaping in the jail
* bundle with inotify watch helpers to detect, report, and quarantinestray files or changed script files
* bundle with optional Linux MAC options that can be set in a textconfig file
* force install to a single user-owned directory either in /opt or$WEBROOT with .htaccess protections, instead of /etc /var or /run
* slowly work on converting the shell installation scripts to purePHP for a word-press like install from the web front end
* assign IDs and access controls to the individual PHP functions,limiting their inputs and outputs on a per file basis
What am I missing so far?
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 65 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 10:54:43 |
| Calls: | 862 |
| Files: | 1,311 |
| D/L today: |
3 files (7,546K bytes) |
| Messages: | 265,264 |