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?
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.
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?
Where would I find such proofs?
The path traversal vulnerability was used to rescue valuablecommunity data from the rocksolidbbs.com server.
On 7/22/2025 9:59 AM, Billy G. (go-while) wrote:
4. Wait for pugleaf.net open source release!
When is that gonna be actually? I wanted to put a web-frontend on one
of my little servers and had planned to use rslight, but then the
whole thing happened.
On 26.07.2025 17:06 Uhr Kyonshi wrote:
On 7/22/2025 9:59 AM, Billy G. (go-while) wrote:
4. Wait for pugleaf.net open source release!
When is that gonna be actually? I wanted to put a web-frontend on one
of my little servers and had planned to use rslight, but then the
whole thing happened.
Ask him directly, I don't see a public release yet and the software
itself seems to be not production-ready yet.
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.
I started programming in PHP back around the time WordPress was first published. So I know enough to fix a lot of things. Given a list of
the relevant files I can scan and suss out bugs for analysis. I'm not
going to scan the whole source code or try to attack active installs
since others already seem to have done this work. Give me the
relevant file names and I'll have a look.
* 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.
--
Пу́тін — хуйло́
https://www.eternal-september.org
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).
if some of the attack vectors are gutted:To make things even worse, there is nobody who is able to revoke
the compromised account or change its password.
--
Пу́тін — хуйло́
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
* remove the file upload and storage feature except for MIME attachmentswith less overhead, just requiring more code, and the main tradeoff is more complex processing versus simple database commands
* 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,
* going forward commit to a prefix-sorted tradspool tree instead of database message storageefficiency
* 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
* 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 fromthere
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: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 546 |
Nodes: | 16 (2 / 14) |
Uptime: | 10:54:17 |
Calls: | 10,389 |
Calls today: | 4 |
Files: | 14,061 |
Messages: | 6,416,855 |
Posted today: | 1 |