1. Forum
  2. DOVE-Net
  3. Synchronet Programming

  • src/sbbs3/js_filebase.c js_msgbase.c

    From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Sat Sep 14 14:20:08 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/a398abb2fe57ee51eb2cde29
    Modified Files:
    src/sbbs3/js_filebase.c js_msgbase.c
    Log Message:
    Don't heap allocate argument to MsgBase and FileBase constructors

    Nelgin reported a weird error with a failed very large allocation for the base/code argument to the FileBase constructor. There's no good reason
    these strings were heap-allocated in the first place, so just change to
    use a stack allocated variable instead. I don't know why this would fix anything, but at least there's one less heap allocation and potential
    for memory leak here.

    Fix 2 bugs in js_update_file():
    1. missing parenthesis (really?!? Caught by Coverity - sigh) in last
    commmit caused attempt/failure/error to remove file after making any
    updates. The removing is only supposed to happen when its necessary to
    remove and re-add the file to the filebase (e.g. updating extended
    description or auxdata).
    2. Wrong filename used in 'removing' exception string.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Wed Sep 3 20:43:12 2025
    https://gitlab.synchro.net/main/sbbs/-/commit/93b4d946cc12ad15f15773af
    Modified Files:
    src/sbbs3/js_filebase.c js_msgbase.c
    Log Message:
    Security improvements to MsgBase and FileBase constructors

    Require an initial 'true' parameter before treating the string argument to
    the constructor as a path/filename to a msg/file base.

    As Deuce discovered, not all scripts (e.g. the legacy/runemaster web UI) do
    a good job of validating client/user-supplied parameters to these constructors so a sysop can end up with some unexplained and suspicious-looking SMB files (e.g. *.sid, *.shd, *.sdt) in their ctrl directory (or possibly, but hopefully not, somewhere else).

    So the old "feature" of supporting an arbitrary msg or filebase path passed to the constructor now requires a unique calling pattern so this shouldn't be
    a problem from now on.

    Also, it appears the arbitrary FileBase creation/opening didn't really work anyway, so that's now fixed.

    Also, do a better job of validating an arbitrary *base path and filename so that malicious(looking) filenames won't be created, ever, using these
    classes.

    And improve the exception/error messages and JSDOCs.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net