A vulnerability was found in Pagure. Support of symbolic links during repository archiving of repositories allows the disclosure of local files. This flaw allows a malicious user to take advantage of the Pagure instance.

A vulnerability was found in Pagure. An argument injection in Git during retrieval of the repository history leads to remote code execution on the Pagure instance.

A vulnerability was discovered in Pagure server. If a malicious user were to submit a git repository with symbolic links, the server could unintentionally show incorporate and make visible content from outside the git repo.

A directory traversal vulnerability was discovered in Pagure server. If a malicious user submits a specially cratfted git repository they could discover secrets on the server.

An argument injection on Git during retrieval of repository history leads to remote code execution on the Pagure instance.

Description of problem: In pagure/lib/git.py, the method updatefileingit() allows updating files on Pagure repositories directly from the web interface. Under the hood, it clones the repository to a temporary folder, performs the write operation, commits the changes and pushes it back to either the default branch or a new one.

def updatefileingit( repo, branch, branchto, filename, content, message, user, email ): # [...] with TemporaryClone(repo, "main", "editfile") as tempclone: # [...] filepath = os.path.join(newpath, filename) # [...] with open(filepath, "wb") as stream: stream.write(content.replace("\r", "").encode("utf-8")) # [...] newrepo.createcommit( # [...] ) # [...] tempclone.push( user.username, nbranchref.name if nbranchref else branchref.name, branchto, )

This code doesn't take enough precautions when dealing with symbolic links: if filepath points to one, open(filepath) will follow it. This link can point outside of the temporary clone folder.

Version-Release number of selected component (if applicable): Likely introduced in commit 54335c2 in release 0.1.11, and verified on latest commit as of today (1b36cb8).

How reproducible: This bug can be reliably exploited on the latest development version of Pagure; see steps below.

Steps to Reproduce: 1. Create a new repository on a test Pagure instance; 2. Clone it locally; 3. From the local clone, run: ln -s /tmp/foo foo; 4. Commit this file, and push the commit back to Pagure; 5. From the web interface, in the "Files" tab, click on the one named foo, and then on the button "Edit"; 6. Put anything in the textarea, and then click on "Commit changes"; 7. Notice that the file /tmp/foo was created on the Pagure server.

Actual results: Calls to updatefileingit() on symbolic links allow attackers to write fully controlled data to arbitrary paths (as long as the system user git has the right permissions on the destination).

I could demonstrate the exploitation of this vulnerability and gain arbitrary code execution on stg.pagure.io by overriding /srv/git/.bashrc. As a proof, here's the output of name -a: Linux pagure-stg01.fedoraproject.org 4.18.0-513.11.1.el89.x8664 #1 SMP Thu Dec 7 03:06:13 EST 2023 x8664 x8664 x8664 GNU/Linux. I've since removed my changes to this file.

Expected results: Calls to updatefileingit() on symbolic links should only be performed if the destination of link stays "within" the temporary clone folder. At first glance, I would not use os.readlink() here, as it would not catch cases where several links are chained; os.path.realpath() seems more appropriate.

Additional info: I haven't had the time to work on a patch for this one, I'll try to submit it in the coming days.

Description of problem: In issues.py, viewissuerawfile() services issues attachments from pagureconfig["ATTACHMENTSFOLDER"]. The requested filename comes directly from the URL and is concatenated with the attachments folder and the repository name.

@UINS.route("/<repo>/issue/raw/<path:filename>") @UINS.route("/<namespace>/<repo>/issue/raw/<path:filename>") @UINS.route("/fork/<username>/<repo>/issue/raw/<path:filename>") @UINS.route("/fork/<username>/<namespace>/<repo>/issue/raw/<path:filename>") @hasissuetracker def viewissuerawfile(repo, filename=None, username=None, namespace=None): # [...] attachdir = os.path.join( pagureconfig["ATTACHMENTSFOLDER"], repo.fullname ) attachpath = os.path.join(attachdir, filename) if not os.path.exists(attachpath): # [...] # At this moment, attachpath exists and points to the file with open(attachpath, "rb") as f: data = f.read() # [...] return (data, 200, pagure.lib.mimetype.gettypeheaders(filename, data))

The "path" routing converter accepts all characters, including slashes and thus also directory traversal sequences.

Version-Release number of selected component (if applicable): Introduced with commit 96c928b in release 3.0, and verified on latest commit as of today (fe91f76).

How reproducible: This bug can be reproduced on the latest development version of Pagure; see steps below.

It is important to note that reverse-proxies in front of Pagure can thwart exploitation attemps depending on their configuration, as they often try to normalize the URL. This is not a security feature and it shouldn't be relied upon.

I could demonstrate it locally but not on stg.pagure.io after succint tests.

Steps to Reproduce: 1. Create a new repository; 2. Go to "Settings", "Project Options" and make sure that "Issue tracker" is ticked; 3. Run the command curl --path-as-is 'http://pagure.local:5000/your-repository/issue/raw/../../../../../../../etc/passwd'.

Actual results: On my test instance, the content of /etc/passwd is shown.

Expected results: Only files under the intended attachments folder should be served.

Additional info: Flask offers flask.sendfromdirectory() (https://flask.palletsprojects.com/en/3.0.x/api/#flask.sendfromdirectory) for such cases.

https://bugzilla.redhat.com/showbug.cgi?id=2279411