CVE-2023-1350 (published 2023-03-11T09:15Z)

A vulnerability was found in liferea. It has been rated as critical. Affected by this issue is the function update_job_run of the file src/update.c of the component Feed Enrichment. The manipulation of the argument source with the input |date &gt;/tmp/bad-item-link.txt leads to os command injection. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. The name of the patch is 8d8b5b963fa64c7a2122d1bbfbb0bed46e813e59. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-222848.

CVSS v3 base score: 9.8, CRITICAL (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)

Weakness information:
cwe_id: CWE-78
cwe_name: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
description: The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component.
extended_description: 
		   This weakness can lead to a vulnerability in environments in which the attacker does not have direct access to the operating system, such as in web applications. Alternately, if the weakness occurs in a privileged program, it could allow the attacker to specify commands that normally would not be accessible, or to call alternate commands with privileges that the attacker does not have. The problem is exacerbated if the compromised process does not follow the principle of least privilege, because the attacker-controlled commands may run with special system privileges that increases the amount of damage.
            There are at least two subtypes of OS command injection:
               
				 The application intends to execute a single, fixed program that is under its own control. It intends to use externally-supplied inputs as arguments to that program. For example, the program might use system("nslookup [HOSTNAME]") to run nslookup and allow the user to supply a HOSTNAME, which is used as an argument. Attackers cannot prevent nslookup from executing. However, if the program does not remove command separators from the HOSTNAME argument, attackers could place the separators into the arguments, which allows them to execute their own program after nslookup has finished executing.
				 The application accepts an input that it uses to fully select which program to run, as well as which commands to use. The application simply redirects this entire command to the operating system. For example, the program might use "exec([COMMAND])" to execute the [COMMAND] that was supplied by the user. If the COMMAND is under attacker control, then the attacker can execute arbitrary commands or programs. If the command is being executed using functions like exec() and CreateProcess(), the attacker might not be able to combine multiple commands together in the same line.
               
            From a weakness standpoint, these variants represent distinct programmer errors. In the first variant, the programmer clearly intends that input from untrusted parties will be part of the arguments in the command to be executed. In the second variant, the programmer does not intend for the command to be accessible to any untrusted party, but the programmer probably has not accounted for alternate ways in which malicious attackers can provide input.
         
         

Fix information:
repo_url: https://github.com/lwindolf/liferea
commit_details: repo_url: https://github.com/lwindolf/liferea
author: Alexandre Erwin Ittner
author_date: 2023-03-05 20:25:00-03:00
msg: Fix RCE vulnerability on feed enrichment

Currently there are a few places in the code that do not check URLs for
the presence of a command prefix, allowing malicious websites to run any
command in the local system.

Trying to run feed enrichment (i.e. after option "Extract full content
from HTML5 and Google AMP" is enabled) in a subscription that produces
this item:

    <item>
      <title>Check /tmp/bad-item-link.txt</title>
      <link>|date &gt;/tmp/bad-item-link.txt</link>
    </item>

will cause Liferea to call update_request_new on URL
"|date >/tmp/bad-item-link.txt" and then blindly run the command. A
similar effect happens when running the feed enrichment in a item that
links to a document like this:

    <!DOCTYPE html>
    <html>
     <head>
      <title>AMP URL RCE PoC</title>
      <link rel="amphtml" href="|date &gt; /tmp/bad-amp-url.txt">
     </head>
     <body>
         Check the results in /tmp/bad-amp-url.txt
     </body>
    </html>

once Liferea tries to load the AMP URL.

There are other calls to update_request_* functions where URLs are
validated correctly (e.g. in feed icons and comments) and do not trigger
this vulnerability. Since the subscription update is the exception where
feed commands are supported (and welcome!) I chose to lock this feature
behind a non-persistent flag and only enable it when required. This is
safer than adding the flag in updateOptions, which is usually reused in
subordinate requests.

This failure exists since commits b8288389820a3f510ef4b21684b22439c41d95a5
and b67dbba73443ab7b36fcd3c78aa803e974c0f23e from Setember 2017.
repository: repo_url: https://github.com/lwindolf/liferea
repo_name: lwindolf/liferea
description: Liferea (Linux Feed Reader), a news reader for GTK/GNOME
repo_language: C
owner: lwindolf
file_changes: filename: subscription.c
change_type: ModificationType.MODIFY
diff: @@ -282,6 +282,7 @@ subscription_update (subscriptionPtr subscription, guint flags)
 			subscription->updateState,
 			subscription->updateOptions
 		);
+		update_request_allow_commands (request, TRUE);
 
 		if (subscription_get_filter (subscription))
 			request->filtercmd = g_strdup (subscription_get_filter (subscription));

programming_language: C
filename: update.c
change_type: ModificationType.MODIFY
diff: @@ -234,6 +234,13 @@ update_request_set_auth_value (UpdateRequest *request, const gchar* authValue)
 	request->authValue = g_strdup (authValue);
 }
 
+void
+update_request_allow_commands (UpdateRequest *request, gboolean allowCommands)
+{
+	request->allowCommands = allowCommands;
+}
+
+
 /* update result object */
 
 updateResultPtr
@@ -672,8 +679,14 @@ update_job_run (updateJobPtr job)
 
 	/* everything starting with '|' is a local command */
 	if (*(job->request->source) == '|') {
-		debug1 (DEBUG_UPDATE, "Recognized local command: %s", job->request->source);
-		update_exec_cmd (job);
+		if (job->request->allowCommands) {
+			debug1 (DEBUG_UPDATE, "Recognized local command: %s", job->request->source);
+			update_exec_cmd (job);
+		} else {
+			debug1 (DEBUG_UPDATE, "Refusing to run local command from unexpected source: %s", job->request->source);
+			job->result->httpstatus = 403;  /* Forbidden. */
+			update_process_finished_job (job);
+		}
 		return;
 	}
 

programming_language: C
filename: update.h
change_type: ModificationType.MODIFY
diff: @@ -103,6 +103,7 @@ struct _UpdateRequest {
 	updateOptionsPtr options;	/**< Update options for the request */
 	gchar		*filtercmd;	/**< Command will filter output of URL */
 	updateStatePtr	updateState;	/**< Update state of the requested object (etags, last modified...) */
+	gboolean	allowCommands;	/**< Allow this requests to run commands */
 };
 
 /** structure to store results of the processing of an update request */
@@ -228,6 +229,21 @@ void update_request_set_source (UpdateRequest *request, const gchar* source);
  */
 void update_request_set_auth_value (UpdateRequest *request, const gchar* authValue);
 
+/**
+ * Allows *this* request to run local commands.
+ *
+ * At first it may look this flag should be in updateOptions, but we can
+ * take a safer path: feed commands are restricted to a few use cases while
+ * options are propagated to downstream requests (feed enrichment, comments,
+ * etc.), so it is a good idea to prevent these from running commands in the
+ * local system via tricky URLs without needing to validate these options
+ * everywhere (which is error-prone).
+ *
+ * @param request      the update request
+ * @param can_run      TRUE if the request can run commands, FALSE otherwise.
+ */
+void update_request_allow_commands (UpdateRequest *request, gboolean allowCommands);
+
 /**
  * Creates a new update result for the given update request.
  *

programming_language: C