Reflected File Download (RFD) is a vulnerability that allows an attacker to craft a phishing URL or page that, when visited, initiates a download of a file containing arbitrary content appearing to have originated from a trusted domain. Because the user has trust in the given domain, he or she is likely to open the downloaded file, potentially resulting in malicious code execution.

In order for an attacker to run a successful RFD attack, the following requirements need to be met:
- The target application reflects user input without proper validation or encoding. This is used to inject a payload.
- The target application allows permissive URLs. The attacker may therefore control the downloaded file's name and extension.
- The target application has a misconfigured Content-Disposition header, allows the attacker to control the Content-Type and/or Content-Disposition headers in the HTTP response, or the target application includes a Content-Type that is not rendered by default in the browser.

For example, if the application uses a Spring Web MVC ContentNegotiationManager to dynamically produce different response formats, it meets the conditions necessary to make an RFD attack possible.

The ContentNegotiationManager is configured to decide the response format based on the request path extension and to use Java Activation Framework (JAF) to find a Content-Type that better matches the client's requested format. It also allows the client to specify the response content type through the media type that is sent in the request's Accept header.

Example 1: In the following example, the application is configured to allow path extension strategy and Java Activation Framework to determine the response's content type:

<bean id="contentNegotiationManager" class="org.springframework.web.accept.ContentNegotiationManagerFactoryBean">
  <property name="favorPathExtension" value="true" />
  <property name="useJaf" value="true" />
</bean>

Example 2: In the following example, the application is configured to allow the request's Accept header to determine the response's content type:

<bean id="contentNegotiationManager" class="org.springframework.web.accept.ContentNegotiationManagerFactoryBean">
  <property name="ignoreAcceptHeader" value="false" />
</bean>

Note that the ContentNegotiationManagerFactoryBean property defaults in Spring 4.2.1 are:

- useJaf: true
- favorPathExtension: true
- ignoreAcceptHeader: false

The configuration shown in Example 1 allows an attacker to craft a malicious URL such as:

http://server/some/resource/endpoint/foo.bat?input=payload

such that the ContentNegotiationManager will use Java Activation Framework (if activation.jar is found in the classpath) to try to resolve the media type for the given file extension and set the response's ContentType header accordingly. In this example, the file extension is "bat", resulting in a Content-Type header of application/x-msdownload (although the exact Content-Type may vary depending on the server OS and JAF configuration). As a result, once the victim visits this malicious URL, his or her machine will automatically initiate the download of a ".bat" file containing attacker-controlled content. If this file is then executed, the victims machine will run any commands specified by the attacker's payload.

The Linux Standard Base Specification 2.0.1 for libc places constraints on the arguments to some internal functions [1]. If the constraints are not met, the behavior of the functions is not defined.


The value 1 must be passed to the first parameter (the version number) of the following file system function:

	__xmknod

The value 2 must be passed to the third parameter (the group argument) of the following wide character string functions:

__wcstod_internal
__wcstof_internal
_wcstol_internal
__wcstold_internal
__wcstoul_internal

The value 3 must be passed as the first parameter (the version number) of the following file system functions:

__xstat
__lxstat
__fxstat
__xstat64
__lxstat64
__fxstat64

Depending on the specific C compiler in use, the address of a system FILE object might be significant to the use of the FILE object as a stream. Using a copy of the FILE object without the associated address can lead to undefined behavior resulting in potential system information leakage, a system crash, or the ability for a malicious actor to read or edit files at their discretion.

Example 1: The following code shows a system FILE object that is dereferenced and copied by value.

FILE *sysfile = fopen(test.file, "w+");
FILE insecureFile = *sysfile;

Because sysfile is dereferenced in the assignment of insecureFile, use of insecureFile can result in a wide variety of problems.

Performing file operations on a system FILE object after its associated stream is closed results in undefined behavior. Depending on the specific C compiler in use, the file operation can cause a system crash or even potentially result in modification or reading of the same or different file.

Example 1: The following code shows an attempt to read a system FILE object after the corresponding stream is closed.

FILE *sysfile = fopen(test.file, "r+");
res = fclose(sysfile);
if(res == 0){
    printf("%c", getc(sysfile));    
}

Because the getc() function runs after the file stream for sysfile is closed, getc() results in undefined behavior and can cause a system crash or potential modification or reading of the same or different file.

Deleting a managed pointer will cause the program to crash or otherwise do the wrong thing when, later on, the pointer management code assumes that the pointer is still valid. The following example illustrates the error.

  std::auto_ptr<foo> p(new foo);
  foo* rawFoo = p.get();
  delete rawFoo;

The only exception to this rule comes when a managed pointer class supports a "detach" operation allowing the programmer to take control of memory management for the given pointer. If the program detaches the pointer from the management class before calling delete, the management class knows not to use the pointer any further.