Posts by Alexander Ebert

    Hello,


    There are three issues here:

    1. The software was unable to connect to MySQL, possibly the socket did not exist, check the database server.
    2. You're using PHP 7.3, but Burning Board 4.1 is so old, it only supports up to PHP 7.2, newer versions cause errors.
    3. Burning Board 4.1 is already end of life, there are no updates or security fixes provided for this version anymore. You should consider upgrading to a newer version.

    Hello,


    You can enforce visitors to log in before being able to access any content on the site. Additionally, you can disable the registration and create users manually through the admin panel for an extra layer of control. There is also a 3rd party plugin available in the official Plugin-Store that adds the concept of sending out invitations required to be able to register:

    We have just released new versions of our products:

    • WoltLab Suite 5.2.6
    • WoltLab Suite 3.1.14


    Stability releases (also known as "minor releases") aim to solve existing problems in the current version. Like every stability release, they do not introduce new features; It is strongly recommended to apply these updates.

    Recent Investigations on Compromised Communities

    We have become aware that a few customer sites have been compromised in an attempt to steal user credentials. The attacker did modify a few files to capture plaintext passwords and installed a backdoor in order to regain access at a later point. This update will overwrite the files containing the malicious changes with the original versions.


    Furthermore, any intercepted plaintext password was stored in the database column logToken in the table wcf1_user that was added by the attacker. This update will nullify those values by replacing them with the string compromised, account that did not have the password stolen will have an empty value.


    If you have any questions or to seek advice if your site had been compromised, please get in touch with us, we'll help you.

    How Did the Attacker Gain Access?

    Investigations strongly indicate that the attacker gained access to the systems by logging in with an administrator's account using credentials that have been stolen previously. We cannot stress this enough: DO NOT REUSE PASSWORDS ON OTHER SITES. YOU PUT YOURSELF AND YOUR COMMUNITY AT RISK!

    Performing System Updates

    Open your Administration Control Panel and navigate to Configuration > Packages > List Packages. Please click on the button Search for Updates located in the right corner above the package list.

    Notable Changes

    The list below includes only significant changes, minor fixes or typos are generally left out.


    WoltLab Suite Blog

    • The detection for mentions was using an inefficient API call and now works much faster. 3.1 5.2
    • Incorrect detection of numeric values in some importers. 3.1 5.2
    • The react button was displayed even when the user lacked the permissions to use it. 5.2

    WoltLab Suite Calendar

    • Incorrect detection of numeric values in some importers. 3.1 5.2
    • Some foreign keys were missing from the SQL log after an upgrade from version 3.1. 5.2
    • The AMP version of the event page has been removed. 5.2

    WoltLab Suite Filebase

    • Editing reviews accidentally created modification log entries to be created for the file. 5.2
    • The AMP version of the file page has been removed. 5.2
    • Incorrect detection of numeric values in some importers. 5.2

    WoltLab Suite Gallery

    • Searching for images with no results yielded an incorrect error message. 3.1 5.2
    • The detection for mentions was using an inefficient API call and now works much faster. 3.1 5.2
    • Incorrect detection of numeric values in some importers. 3.1 5.2

    WoltLab Suite Forum

    • Copying forums did not preserve the flag for private threads. 3.1 5.2
    • The detection for mentions was using an inefficient API call and now works much faster. 3.1 5.2
    • Moderators were unable to move or copy posts into forums that are hidden from the forum list. 3.1 5.2
    • Incorrect detection of numeric values in some importers. 3.1 5.2
    • Copying forums did not preserve the flag for best answers. 5.2
    • The AMP version of the thread page has been removed. 5.2
    • Any error that occurs when creating a thread could cause the thread forms to reset on page load. 5.2

    WoltLab Suite Core: Conversations

    • Checking the location of a user who's an invisible participant in one's conversations would indirectly expose this participant. 3.1 5.2
    • Revoking the permissions to use the conversation system did not exclude messages from search results. 3.1 5.2

    WoltLab Suite Core

    • Incorrect detection of numeric values in some importers. 3.1 5.2
    • Editing a user with a cover photo, without having the permissions to view it, caused the cover photo to be discarded. 3.1 5.2
    • Trophies could sometimes be awarded more than once. 3.1 5.2
    • ImageMagick support for image processing
      • Some thumbnails were created with larger than requested dimensions. 3.1 5.2
      • Normalizing images based on their EXIF rotation previously did not update the orientation information. 3.1 5.2
      • Writing text on it caused it to be positioned incorrectly. 3.1 5.2
      • The font size of text was treated as pt, but actually expects px values (the doc at php.net is misleading). 3.1 5.2
    • Scrolling a tab menu on iOS caused the items to be unresponsive for a few moments. 3.1 5.2
    • Older moderation queue entries have sometimes not been removed. 3.1 5.2
    • Adding keywords to the search list could fail due to a race condition. 5.2
    • Descriptions of categories with HTML were improperly displayed. 5.2
    • The dynamic image resizing in the browser produced damaged images due to a bug in Chrome 81. 5.2
    • Prevent the quote tooltip from being selected on mobile devices. 5.2
    • Replace legacy <font> elements injected by some browser. 5.2
    • Improved the main menu navigation on large Android tablets. 5.2
    • Sorting of trophies did not work properly when split across multiple pages. 5.2

    WoltLab Suite 3.0 was released on January 11th 2017 and its guaranteed support period has ended on Feburar 28th, 2020, two years after the final release of its successor WoltLab Suite 3.1. We'll continue to provide security updates for the WoltLab Suite 3.0 series for a limited time, before dropping the support entirely.


    Affected Products

    • WoltLab Suite Forum 5.0
    • WoltLab Suite Core 3.0
    • WoltLab Suite Blog 3.0
    • WoltLab Suite Calendar 3.0
    • WoltLab Suite Filebase 3.0
    • WoltLab Suite Gallery 3.0

    March 1st, 2020 - Stage 1

    • End of the regular support period.
    • Updates will be released for security issues only.
    • PHP 7.4 is the last supported PHP version.

    March 1st, 2021 - Stage 2

    • End of the extended support period, there will be no more updates being released.
    • The ticket support will be limited to the WoltLab Suite 3.1 and newer products only.

    March 1st, 2022 - Stage 3

    • The downloads in the customer area will be removed.
    • The package update servers for the affected products will be shut down.
    • Any files in the Plugin-Store for these versions will be removed.

    However, i don't understand the problem at all. Where's the drawback, if you just remove the @ sign and stop suppressing any errors?

    Try requesting a controller that is a form or try to use {$foo|trim}. We (and quite a few plugins) do use negative lookups to dynamically determine code paths.


    I will look into a potential code branch when running in the developer mode for 5.3.

    Hello,


    Removing the @ is not an option, we're relying on the side effect of include*() that implicitly checks for the existence of the requested file. Running an explicit check via file_exists() or is_readable() is quite expensive at this point, because PHP tends to skip the statcache under certain circumstances. This has a significant performance penalty for sites running on cheaper webhosting offers that still make use of "spinning rust" (HDD).


    The original issue can be easily avoided by using a proper IDE with static code analysis (for example, Visual Studio Code would do) that will report these kind of issues ahead of time.


    We're not going to make any changes at this time, because the drawbacks of such a change are too severe with little to no benefit on average. Furthermore, this is not a bug, because the code does exactly what is was purposely instructed to do.

    Hello,


    Actually, you can do both. This specific section of the forum is configured to allow replies only to threads that you have started, with the exception of staff members.


    There is also another feature called "Private Forum" that works similar, but with the difference that threads are only visible to the starter and select user groups (such as staff members). You can try it out in this section which operates in this mode: Private Test Forum.

    We have just released an update for the package "WoltLab Suite Core: Conversations" that addresses one major and one minor issue.

    Abuse of Conversations for the Purpose of Sending Spam

    We have become aware of a sophisticated bot that specifically targets the conversation system of our software in an attempt to mass send messages to registered users. The attack pattern consists of two phases, in the first phase the members list is scraped to collect the list of usernames. The second phase involves the start of a new conversation with each user previously found in the first phase, with the advertisement placed in the start message. The bot has also been programmed to immediately leave the conversations in an effort to circumvent the limit of the number of active conversations per user.


    Following these events, we have implemented a new restriction in order to mitigate this kind of attack and to prevent further abuses in that direction. WoltLab Suite 3.0, 3.1 and 5.2 just received an update to the conversation system that limits the number of started conversations within a rolling 24 hour period. The default value enforces a limit of 10 for regular users, administrators are not restricted by this new permission.


    Site owners can adjust the limits per user group, with the special value -1 used to remove the limit entirely for select user groups. The permission is named Maximum Number of Started Conversations per 24 Hours.

    Minor Issue: Potential Leak of Invisible Participants of Conversations

    This update also resolves an issue that allowed to indirectly probe for hidden participants by abusing the participant filter in the conversation list and comparing the result to the actual participant list. We have resolved this issue and have also identified a potential performance bottleneck that has been fixed too.

    Hello,


    CMS pages themselves only offer distinct URLs per language, because having the same page appearing in different languages does confuse search engines. It will cause them to index the page in one language on one day and in the other language on the other day, a true nightmare. We strongly recommend using CMS pages with different URLs per language.


    However, system type pages can make use of phrases and thus present different translations based on the interface language while still using the same URL. This is not possible through the UI itself, but must be hand crafted by writing a plugin.

    We have just released new versions of our products:

    • WoltLab Suite 5.2.5
    • WoltLab Suite 3.1.13
    • WoltLab Suite 3.0.24


    Stability releases (also known as "minor releases") aim to solve existing problems in the current version. Like every stability release, they do not introduce new features; It is strongly recommended to apply these updates.

    Users Sending Emails to Users

    The software contains a legacy feature that enables users (and if configured, also guests) to send emails to other users. This feature has little use today, but is more often than not overlooked by administrators, especially those migrating from previous versions. The form uses a dedicated group permissions that was enabled by default in previous versions and was often left unchanged.


    It has come to our attention that attackers take advantage of this feature and actively abused it to send out spam emails to other users. We've taken two steps to mitigate this issue to some extent:

    1. Force revoked the group permissions to use this form. Site owner can grant the permissions again at their own discrection, although we strongly advise against this.
    2. The captcha protection of the mail form was previously enabled for guest access only and is now enforced for users alike. This is the first form to enforce the captcha for logged-in users too.

    This change has previously been applied to the 5.2 series and is now in full effect for the entire WoltLab Suite 3.x series.

    Performing System Updates

    Open your Administration Control Panel and navigate to Configuration > Packages > List Packages. Please click on the button Search for Updates located in the right corner above the package list.

    Notable Changes

    The list below includes only significant changes, minor fixes or typos are generally left out.

    WoltLab Suite Blog

    • Pages excluded from access by search engines were incorrectly listed in the sitemap. 3.1

    WoltLab Suite Calendar

    • Pages excluded from access by search engines were incorrectly listed in the sitemap. 3.1

    WoltLab Suite Filebase

    • Pages excluded from access by search engines were incorrectly listed in the sitemap. 3.1
    • File owners were unable to delete responses to reviews despire having the permissions. 5.2

    WoltLab Suite Gallery

    • The list of deleted images raised an exception when viewed by guests. 3.0 3.1
    • Pages excluded from access by search engines were incorrectly listed in the sitemap. 3.1

    WoltLab Suite Forum

    • Attempting to move a thread raised an exception in PHP 7.4. 5.0 5.1
    • Pages excluded from access by search engines were incorrectly listed in the sitemap. 5.1 5.2

    WoltLab Suite Core: Conversations

    • Resolved an issue when replying to conversations when one or more participants were deleted. 3.0 3.1
    • The import from vBulletin could fail due to an incorrect recognition of numeric values. 3.0 3.1 5.2

    WoltLab Suite Core

    • Resolved two compatibility issues with PHP 7.4. 3.0 3.1
    • Reading articles yielded an incorrect location in the users online list. 3.0 3.1 5.2
    • Requests dispatched through HTTPRequest would not apply the timeout value to the stream itself. 3.0 3.1 5.2
    • Improved the behavior of the mobile message UI. 3.1
    • Optimized the processing speed of messages with excessive amounts of HTML nodes. 3.1 5.2
    • An incorrect sort direction caused packages installed via the package server to sometimes favor older versions over newer ones. 3.1 5.2
    • Removed the compatibility check for the API versions. 3.1
    • Overly restrictive permission checks for non owner groups. 5.2

    Hello,


    Each concurrent request hitting your site consumes one connection to the database server. If you have a larger number of concurrent visitors or make use of plugins that dispatch a large number of requests, then it could happen that there are too many in-flight requests, consuming all connections granted by your webhost. This can be even worse on slower hosts, because the longer it takes to process a request, the longer this connection slot is taken up.