• Is Rocksolid Light really compromised and insecure?

    From Anonymous@21:1/5 to All on Sat Jul 12 10:21:19 2025
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco Moock@21:1/5 to All on Sat Jul 12 20:55:07 2025
    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.

    --
    kind regards
    Marco

    Send spam to 1752308479muell@stinkedores.dorfdsl.de

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ray Banana@21:1/5 to All on Sat Jul 12 19:41:55 2025
    * 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Retro Guy@21:1/5 to All on Sat Jul 12 20:15:08 2025
    Yes.

    --
    Retro Guy

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Billy G. (go-while)@21:1/5 to Anonymous on Tue Jul 22 09:59:56 2025
    On 12.07.25 17:21, 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?

    Where would I find such proofs?


    Yes and if anyone is still running [rocksolid / rslight] (PHP):

    1. Turn it off!
    2. Backup /etc/rslight and /var/spool/rslight folders!
    3. Do NOT delete any configs or data!
    4. Wait for pugleaf.net open source release!
    5. Import to new software and be happy!

    If you don't want to turn your rslight off...
    Deny access from public and use it locally only.

    The path traversal vulnerability was used to rescue valuable
    community data from the rocksolidbbs.com server.

    Works on all other domains too and there is nobody to install a patch.. Passwords are already leaked... kids found the way in...

    That's not the only vulnerability but i won't publish any more details.

    We'll see how long his servers and sites keep running.

    Domain expiry = end of life for the sites

    novabbs.com / novabbs.org / novalink.us will expiry in jan/feb 2026. rocksolidbbs.com in end of nov 2025 and i2pn2.org end of the year 2025.

    Maybe there is credit... but if not ...

    ... RIP Retro Guy ...

    https://github.com/go-while/rocksolid-light/blob/claude-sonnet-4-test2/Rocksolid_Light/CRITICAL_VULNERABILITY.md

    https://github.com/go-while/rocksolid-light/tree/claude-sonnet-4-test2

    https://github.com/go-while/rocksolid-light

    🚨 CRITICAL SECURITY NOTICE

    This codebase contains multiple critical security vulnerabilities and is
    no longer under active development.
    Status: DEPRECATED AND UNSAFE FOR PRODUCTION USE

    Path Traversal Vulnerabilities: Complete file system access possible
    SQL Injection Attacks: Database compromise via multiple vectors
    Input Validation Failures: User input processed without
    sanitization throughout
    Legacy PHP Anti-Patterns: 20-year-old vulnerable coding practices
    Architectural Security Flaws: No security boundaries or privilege separation

    Evidence of Active Exploitation

    This codebase was actively compromised for over 1 year (May 2024 - June
    2025) with evidence of:

    Automated SQL injection campaigns
    File system pollution via malicious newsgroup names
    Systematic database content extraction
    Hundreds of attack artifacts preserved in the filesystem

    Why Development Has Stopped

    After comprehensive security analysis, this codebase is beyond repair:

    50+ distinct attack vectors across all major components
    No security architecture to retrofit modern protections
    Interconnected vulnerabilities where fixes create new problems
    Legacy dependencies that prevent meaningful security improvements


    📧 SECURITY ADVISORY FOR ROCKSOLID LIGHT ADMINISTRATORS
    Subject: CRITICAL SECURITY VULNERABILITIES - Immediate Action Required

    To: RockSolid Light Administrators From: Security Research Team Date:
    June 20, 2025 Severity: CRITICAL

    🚨 EXECUTIVE SUMMARY

    Multiple critical security vulnerabilities have been discovered in
    RockSolid Light installations,

    with evidence of active exploitation spanning May 2024 - June 2025.

    Any RockSolid Light instance running during this period should be
    considered potentially compromised.

    ⚠️ IMMEDIATE ACTION REQUIRED

    You are running RockSolid Light:

    Take your installation offline immediately
    Audit your system logs for suspicious activity
    Check your spool directory for unusual files (see indicators below)
    Consider your system potentially compromised
    Do not restart without applying security fixes

    🔍 VULNERABILITY DETAILS
    Primary Vulnerability: Path Traversal (CVE Pending)

    File: /var/www/html/spoolnews/files.php
    Impact: Complete file system access
    Exploitation: Active attacks documented since May 2024

    Vulnerable Code Pattern:

    // files.php - Critical path traversal
    $getfilename = $spooldir . '/upload/' . $_REQUEST['showfile']; readfile($getfilename); // NO PATH VALIDATION

    Attack Vector:

    Attacker extracts site key from HTML form
    POST request with malicious showfile parameter
    Can read any system file accessible to web server
    Enables extraction of SSH credentials, database contents,
    configuration files

    Secondary Vulnerability: SQL Injection via Newsgroup Names

    Impact: Database manipulation and file system pollution
    Evidence: Hundreds of malicious database files found
    Attack Method: Injection through NNTP protocol and group name
    processing

    🕵️ COMPROMISE INDICATORS

    Check your spool directory for files with suspicious names:

    # Look for files containing SQL injection patterns
    find /var/spool/rslight -name "*CASE WHEN*" -o -name "*SELECT*" -o -name "*UNION*"
    find /var/spool/rslight -name "*ORDER BY*" -o -name "*CONCAT*" -o -name "*CHAR(*"

    Example malicious filenames found:

    (CASE WHEN (2018=4830) THEN 'newsgroup' ELSE SELECT...)-data.db3 comp.lang.python' WHERE 7629=7629 AND 5482=CONCAT...-data.db3 DOVE-Net.Synchronet_Announcements ORDER BY 3123-- fnTQ-cache.txt

    If you find such files, your system has been compromised.
    🎯 ATTACK TIMELINE

    May 2024: First evidence of SQL injection attacks
    May 2024 - June 2025: Continuous automated exploitation
    March 2025: Retro Guy's system was under active attack during his
    final months
    June 2025: Vulnerabilities discovered and documented

    💾 DATA AT RISK

    Potentially Compromised Information:

    System/Web configuration files and encryption keys
    All newsgroup content and user messages
    User account databases and authentication data
    SSH credentials and server access
    Email addresses and user metadata
    Any sensitive data accessible to the web server

    🛠️ IMMEDIATE REMEDIATION STEPS

    Emergency Shutdown

    # Stop web server and NNTP service immediately
    systemctl stop apache2 nginx

    Evidence Preservation

    # Backup current state for forensic analysis
    tar -czf rocksolid-incident-$(date +%Y%m%d).tar.gz /var/spool/rslight/

    This vulnerability was discovered during a digital preservation effort following Retro Guy's passing in March 2025.

    The path traversal vulnerability was used to rescue valuable community
    data from the rocksolidbbs.com server.

    ------------------------------------------------------------- ------------------------------------------------------------- -------------------------------------------------------------


    --
    .......
    Billy G. (go-while)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco Moock@21:1/5 to All on Sat Jul 26 17:49:23 2025
    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.

    --
    kind regards
    Marco

    Send spam to 1753542389muell@stinkedores.dorfdsl.de

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Billy G. (go-while)@21:1/5 to Marco Moock on Sat Jul 26 22:31:49 2025
    XPost: rocksolid.nodes.help, rocksolid.nodes.announce

    On 26.07.25 17:49, Marco Moock wrote:
    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.


    no ETA. It's done when it's done!
    still host breaking memory issues hidden in the code
    fetched and processed 800 GB of articles in 48h hours without crashing.
    sucking with 1000-2000 connections :D .. but mem goes up ..

    memory issue is maybe fixed now
    but found breaking bug in history / hashdb and need rebuild all now :D

    who wants, can join: https://discord.gg/rECSbHHFzp


    --
    .......
    Billy G. (go-while)
    https://pugleaf.net
    @Newsgroup: rocksolid.nodes.help

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Soul Patch@21:1/5 to Marco Moock on Mon Aug 4 18:23:11 2025
    On Sat, 12 Jul 2025 20:55:07 +0200
    Marco Moock <mm@dorfdsl.de> 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.

    I wouldn't be so quick to throw away the whole code base upon the claim that bugs can't be remediated. Give me a complete list of all the files where vulnerabilities were found.

    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.

    --
    Soul Patch

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco Moock@21:1/5 to All on Tue Aug 5 20:14:36 2025
    On 04.08.2025 18:23 Uhr Soul Patch wrote:

    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.

    - **File**: `/var/www/html/spoolnews/files.php`
    #### Secondary Vulnerability: SQL Injection via Newsgroup Names

    IIRC there was also a document published on github that provided more
    details.

    --
    kind regards
    Marco

    Send spam to 1754324591muell@stinkedores.dorfdsl.de

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Soul Patch@21:1/5 to Ray Banana on Tue Sep 2 16:26:04 2025
    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.

    --
    Пу́тін — хуйло́
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Soul Patch@21:1/5 to Soul Patch on Tue Sep 2 16:37:31 2025
    On Tue, 2 Sep 2025 16:26:04 -0500
    Soul Patch <soul.patch@127.0.0.1> wrote:

    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.

    --
    Пу́тін — хуйло́
    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?


    Addendum:

    * configure all scripts and PHP files to prohibit any invocation as root user by checking to SUID / RUID at beginning of every script

    * prohibit running install scripts as root user, except to request root for registering init / systemd service for the sync job / cron job

    * add a script to automatically check file permissions, report discrepancies, and correct wrong permissions automatically

    * bundle with firejail / jailkit / lxd / chroot options including network shaping in the jail

    * bundle with inotify watch helpers to detect, report, and quarantine stray files or changed script files

    * bundle with optional Linux MAC options that can be set in a text config 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 pure PHP 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Billy G.@21:1/5 to Soul Patch on Wed Sep 3 00:44:07 2025
    On 02.09.25 22:26, Soul Patch wrote:
    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?


    Addendum:

    * configure all scripts and PHP files to prohibit any invocation as
    root user by checking to SUID / RUID at beginning of every script

    * prohibit running install scripts as root user, except to request
    root for registering init / systemd service for the sync job / cron job

    * add a script to automatically check file permissions, report
    discrepancies, and correct wrong permissions automatically

    * bundle with firejail / jailkit / lxd / chroot options including
    network shaping in the jail

    * bundle with inotify watch helpers to detect, report, and quarantine
    stray files or changed script files

    * bundle with optional Linux MAC options that can be set in a text
    config 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 pure
    PHP 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?

    you did not try yet. touch some lines of rocksolid code
    and see how other parts of the world start breaking :D

    maybe easier to write clean from scratch but go ahead
    respect will be with you if you work your list!

    i stopped working here and i will not continue writing anymore php. https://github.com/go-while/rocksolid-light/pull/2/files

    this is the future: https://github.com/go-while/go-pugleaf



    --
    .......
    Billy G. (go-while)
    https://pugleaf.net
    @Newsgroup: rocksolid.nodes.help
    irc.pugleaf.net:6697 (SSL) #lounge
    discord: https://discord.gg/rECSbHHFzp

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)