SAPCAR (older version was called CAR) is a compress utility (similar to winzip. Operating Systems, the executables are called SAPCAR.EXE and CAR.EXE. Jan 18, 2017 - SAP Router Installation step by configuring email Log after adding roles. Need exact location to download sapcar.exe - Community Archive.
In this blog post, we will cover the analysis and exploitation of a simple heap buffer overflow found in SAPCAR.
SAP published security note #2441560 classifying the issue as 'Potential Denial of Service'. This post is our attempt to show that code execution is not only possible but also relatively easy to achieve. The idea is to provide a (hopefully!) cohesive example for other beginners that might be interested in binary exploitation. We will see one possible approach to make sense out of a few hundred crashes obtained through fuzzing, how to identify the root cause of the bug, and how to determine its exploitability. Afterwards, we will develop an exploit using the old and well known file pointer overwrite technique. The last section will go into some more detail about a relevant mitigation implemented in glibc 2.24.
We consider this post to be merely educational, as mounting an attack against a SAP system administrator would require a more reliable exploit (more details are presented in section 4.4).
- Mar 11, 2013 Dear all, Can you please help me to find SAPCAR for Linuxx8664? I've found the SAPCAR30.exe. Support Packages and Patches - S ' SAPCAR ' SAPCAR 7.20 SAPCAR 7.20 - Linux on x8664 64bit And now how can I use this exe file to move in t.
- Sep 24, 2014 Lately I had to use this tool quite often so I thought I prepare for myself short guide with most used parameters of SAPCAR as an reference for me. Information about SAPCAR and environment: sapcar h. It shows basic information on SAP kernel release, compilation info, supported SAP environment and OS information.
- Aug 03, 2016 To extract SAR file command is below using SAPCAR sapcar -xvf filename.sar (this to extract single sar file) To extract multiple SAR files Go to the folder when you are all SAR files and execute below command.
About the vulnerable software
SAPCAR is a command line utility to work with SAR and CAR archives, which are proprietary archive file formats used by SAP. SAP usually distributes software and packages using this format.
The bug covered in this blog post affects version 721.510 of SAPCAR. Other products and versions might be affected too, but we only tested this particular version.
Crash analysis
The starting point were 507 files that made the SAPCAR binary crash, all of them graciously provided by @martingalloar. The crashes were found using the honggfuzz fuzzer. In particular, the fuzzer was testing the archive contents listing feature, which is invoked with the -tvf command line arguments.
The file names created by honggfuzz contain some relevant information about the crash, such as the program counter register address (which instruction was being executed at the time of the crash), and the description of which signal terminated the process. A sample file looks like this:
A quick inspection of the crashes showed that the PC (program counter) value was repeated several times. This is an indication that the number of unique crashes might be lower than the amount of crashing files. The exact amount of unique PC addresses can be determined with the following command:
This is good news. We are dealing with 13 different crashing points instead of 507.
How To Use Sapcar
Triaging crashes
The next logical step is to determine where and why each of the input files is making the binary to crash. For 13 crashes, we could just run the program attached to a debugger and inspect the registers and memory layout at the time of crash. However, it would be nice to extend this approach to handle a larger number of input files.
Luckily for us, there are a couple of tools that can assist us in this endeavor. One of them is the exploitable plugin for gdb. This plugin attempts to classify crashes by severity and likelihood of exploitability. In order to do this, it relies on a set of heuristics that analyze the state of the application that is being debugged.
The exploitable plugin still requires us to run each of the crashing files through gdb. In an attempt to automate this process, we will rely on the crashwalk utility developed by Ben Nagy. It still uses the same gdb plugin, but it eases the task of processing a large number of crashes, providing access to the results in various formats. Installation steps follow:
Crashwalk had some issues picking up the file names as they were, so we did a quick renaming of the crashes to avoid problematic characters and ran the tool:
cwtriage will output results for each crash file, and store everything in the crashwalk.db database by default. We can then query this database using cwdump.
The output includes a classification of the exploitability of the bug. Of course it is not guaranteed and just based on the heuristics used by the exploitable plugin, but it is still a great way to prioritize analysis. We are interested in exploitable bugs, so let's query the crashwalk database to see if there are any:
We will focus on this input file.
I like the gdb-peda plugin, so I will use it for the following tests. There are more active projects such as gef and pwndbg, but I have not tried them yet.
I like the gdb-peda plugin, so I will use it for the following tests. There are more active projects such as gef and pwndbg, but I have not tried them yet.
Running the SAPCAR binary from gdb shows the following output:
How To Use Sapcar Extract
There is something interesting here: pointers to the FILE structure usually end up in the heap. However, in this case it is pointing to somewhere in the text segment:
Finding where this file pointer is located and inspecting the surrounding memory shows data that looks a lot like the input file contents:
A quick grep shows that these values are present in our test file. In particular, they are located at the very end of it:
Can we overwrite more data in the heap? A simple test consists of appending content to the input file and re-running the binary:
This time the crash happens in _IO_feof, and we fully control the value of the file pointer:
Finding the root cause of the bug
Inspecting the back-trace of all stack frames with the bt command, we find the function that calls feof:
Had the file pointer been overwritten when fread at 0x438719 was called, the program would have crashed in fread instead. There is a good chance that this call to fread is the one actually doing the overwrite.
To verify this, we place a breakpoint in fread and re-run the program. In addition, we want to check what is happening to the original file pointer, so we will place a watchpoint that stops execution whenever it is overwritten. We can get the original address of the file pointer by inspecting the parameters passed to any of the file IO functions before the overwrite.
We see the first assignment, which is correct:
Avery ® Addressing Labels for Laser and Inkjet Printers, 30 labels per sheet. Template 8660, 30 per Sheet. Customize your own unique look for your next big mailing project with these Easy Peel Address Labels. Our downloadable templates are easy to use and can be customized within minutes. At Avery.com, you'll find office supplies and products such as labels, dividers, notetabs and binders. You can also browse our website to find ready-made templates. Free customizable iWork Avery templates for Mac Pages and Numbers, including Avery business card templates, return address labels, file folder labels, notecards, place cards, and more.
If you use Microsoft Office 2011 on a Mac computer, you can easily import addresses or other data from an Excel spreadsheet or from your Apple Contacts and add them to Avery Labels, Name Badges, Name Tags or other products. The Mail Merge Manager built into Microsoft Word for Mac makes it easy to import, then edit and print.
And a second write as a result of the overflow:
So, we can see that fread is called to read 0xb5ef bytes, resulting in the file pointer overwrite.
Monitoring what is being read sheds some light over the file structure too.
Monitoring what is being read sheds some light over the file structure too.
Valid block types are DA, ED, UD, and UE. When the file contains another identifier the program will read 32 additional bytes containing some file metadata about which we do not know any details. However, inspecting the last 4 bytes of the input read at #9 shows that it actually contains the size of the next fread.
Editing those bytes in the input file allows us to control the size passed to fread (up to 2 bytes).
One would think that after the size is read, a new call to malloc is done. However, this proved not to be true in this case, which suggests that the program relies on a fixed size buffer. Monitoring previous accesses to malloc and back-tracing the execution flow from there showed an allocation of a fixed 0x1100 bytes buffer prior to the fread that triggers the issue:
One would think that after the size is read, a new call to malloc is done. However, this proved not to be true in this case, which suggests that the program relies on a fixed size buffer. Monitoring previous accesses to malloc and back-tracing the execution flow from there showed an allocation of a fixed 0x1100 bytes buffer prior to the fread that triggers the issue:
This is the buffer that is later on passed to fread. The overflow is clear now: we are copying an arbitrary amount of data (up to 0xffff in size) into a buffer of size 0x1100.
We also know that it happens because the program determines a dynamic size based on some metadata located in the input file when the block type is unknown.
Armed with this knowledge, we can craft a simple exploit to gain code execution.
We also know that it happens because the program determines a dynamic size based on some metadata located in the input file when the block type is unknown.
Armed with this knowledge, we can craft a simple exploit to gain code execution.
Exploit
Heap exploitation is a creative process, with a lot of techniques and voodoo-like tricks that usually depend on being able to trigger (semi) reliable allocations and deallocations. A great resource to learn about these techniques is the how2heap repository that the guys from Shellphish put together.
However, in this case exploitation is very straightforward. We know we can overwrite a pointer to a FILE structure, which is sufficient to gain code execution. The technique is very old, but it still remains relevant.
There is a great writeup by Kees Cook on abusing the FILE structure, which you should definitely read.
The main idea is that when a new FILE structure is allocated as a result of a call to fopen, glibc will actually allocate an internal structure that contains the struct _IO_FILE and a pointer to another structure called _IO_jump_t, which stores function pointers associated with the different file operations:
Since we control the file pointer and the data that is read from the input file, we can craft a fake FILE structure and set a custom vtable pointer.
We will use the pysap library to craft CAR archives without hassle. The library can be easily installed with pip:
We will use the pysap library to craft CAR archives without hassle. The library can be easily installed with pip:
Overwriting the file pointer
The first step is to overwrite the file pointer with an arbitrary value. We fill the 0x1100 bytes buffer, add some bytes to fill the heap until where the pointer is located, and then overwrite it.
Run the PoC to create the poc.car file, and run it attached to gdb:
Controlling the execution flow
The next step is to store a fake FILE structure followed by a pointer to our vtable. We are running with ASLR disabled for now, so for testing purposes we can rely on a hard-coded buffer address.
We create the new archive and run the binary again. This time we will control RIP and redirect execution as expected:
We can also inspect the file pointer to check that our fake structure was populated correctly (see _IO_new_fclose in the excerpt above):
Spawning a shell
Once in control of the execution flow, there are several alternatives to spawn a shell. Because of NX, we cannot execute code from the heap directly. However, it would be possible to place a ROP chain on the heap, and then pivot the stack pointer to the controlled memory.
Another alternative for the lazy folks is doing system('/bin/sh'). The binary itself provides a call system gadget, and because it is not a PIE executable, the location will remain fixed between runs:
Another alternative for the lazy folks is doing system('/bin/sh'). The binary itself provides a call system gadget, and because it is not a PIE executable, the location will remain fixed between runs:
The parameter to system is a pointer to the command being executed, and should be passed on the RDI register. Inspecting the contents of this register at the time of the crash, we can see that it is pointing to the flags string in our fake FILE structure:
This means we can place the sh string in this buffer, redirect execution to call system and get a shell.
If we do the changes and run the program, we will notice that we are back in the segmentation fault inside _IO_feof.
If we do the changes and run the program, we will notice that we are back in the segmentation fault inside _IO_feof.
The problem is that we have changed the flags, and the file functions are now trying to access the _lock pointer. We can get around this by keeping the correct flags and appending ';sh' to execute a shell.
The only modifications from the previous exploit are changing the flags to:
The only modifications from the previous exploit are changing the flags to:
and setting the function pointers in the vtable to the call system gadget:
Running the binary against the updated exploit file dumps a shell:
Fighting against ASLR (dirty dirty)
So far we have only run the program inside gdb, which disables address randomization. The good news is that we only rely on a single fixed address. The location of the call system gadget will not change, the relative offsets will (most likely) not change, and we know RDI will be pointing to the shell command we want to execute. The problem is the location of our buffer in the heap.
Modern exploits usually require an information leak vulnerability in order to calculate relative addresses. I was not able to find one, so the quick and dirty approach to provide a PoC that runs outside of gdb involves brute-forcing.
Heap addresses are usually low, and after a few runs it becomes clear that the last 12 bits are fixed on any given system. We can just grab a valid value from a call to fread and run the program until that heap base is present again, which will eventually happen after a few thousand runs. On my test system, one sample address was 0x19e7798.
Modern exploits usually require an information leak vulnerability in order to calculate relative addresses. I was not able to find one, so the quick and dirty approach to provide a PoC that runs outside of gdb involves brute-forcing.
Heap addresses are usually low, and after a few runs it becomes clear that the last 12 bits are fixed on any given system. We can just grab a valid value from a call to fread and run the program until that heap base is present again, which will eventually happen after a few thousand runs. On my test system, one sample address was 0x19e7798.
Doing a real bypass of ASLR is left as an exercise for the reader.
Does this still work?
It does, unless you are running glibc versions 2.24 (released on 2016-08-04) or 2.25 (release on 2017-02-01).
Florian Weimer from RedHat implemented some hardening in mid 2016:
Florian Weimer from RedHat implemented some hardening in mid 2016:
''
This commit puts all libio vtables in a dedicated, read-only ELF section, so that they are consecutive in memory. Before any indirect jump, the vtable pointer is checked against the section boundaries, and the process is terminated if the vtable pointer does not fall into the special ELF section.
''
This commit puts all libio vtables in a dedicated, read-only ELF section, so that they are consecutive in memory. Before any indirect jump, the vtable pointer is checked against the section boundaries, and the process is terminated if the vtable pointer does not fall into the special ELF section.
''
This means our exploit would crash immediately instead of executing pointers from the vtable we constructed.
At the time of writing, an up-to-date Ubuntu 16.04.2 is running glibc 2.23 by default. I suspect it takes time for distros to update the glibc version, so this ancient technique might still live for a bit longer.
At the time of writing, an up-to-date Ubuntu 16.04.2 is running glibc 2.23 by default. I suspect it takes time for distros to update the glibc version, so this ancient technique might still live for a bit longer.
References
[1] https://www.coresecurity.com/advisories/sap-sapcar-heap-based-buffer-overflow-vulnerability
[2] https://github.com/google/honggfuzz
[3] https://github.com/jfoote/exploitable
[4] https://github.com/bnagy/crashwalk
[5] https://github.com/longld/peda
[6] https://github.com/hugsy/gef
[7] https://github.com/pwndbg/pwndbg
[8] https://github.com/shellphish/how2heap
[9] https://outflux.net/blog/archives/2011/12/22/abusing-the-file-structure/
[10] https://github.com/CoreSecurity/pysap
[11] https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=db3476aff19b75c4fdefbe65fcd5f0a90588ba51;hp=64ba17317dc9343f0958755ad04af71ec3da637b
[2] https://github.com/google/honggfuzz
[3] https://github.com/jfoote/exploitable
[4] https://github.com/bnagy/crashwalk
[5] https://github.com/longld/peda
[6] https://github.com/hugsy/gef
[7] https://github.com/pwndbg/pwndbg
[8] https://github.com/shellphish/how2heap
[9] https://outflux.net/blog/archives/2011/12/22/abusing-the-file-structure/
[10] https://github.com/CoreSecurity/pysap
[11] https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=db3476aff19b75c4fdefbe65fcd5f0a90588ba51;hp=64ba17317dc9343f0958755ad04af71ec3da637b
File type | SAR Compressed Format Archive (SAPCAR Archive) |
Developer | SAP AG |
Ads |
What is a SAR file?
SAR filename extension is associated with SAPCAR, a simple fle archiver developed by SAP AG for its Phoenix Server software. SAR store archived files in a compressed form.
SAPCAR was released only for Windows, just like its predecessor, CAR, which used CAR files. The new application is a signifacant upgrade over CAR and thus developers decided to change the filename extension used by SAPCAR files.
Program(s) that can open the .SAR file
![How How](https://itsiti.com/wp-content/uploads/2010/10/SAPCAR-tvf.jpg)
How to open SAR files
If you cannot open the SAR file on your computer - there may be several reasons. The first and most important reason (the most common) is the lack of a suitable software that supports SAR among those that are installed on your device.
A very simple way to solve this problem is to find and download the appropriate application. The first part of the task has already been done – the software supporting the SAR file can be found in the table. Now just download and install the appropriate application.
Possible problems with the SAR format files
The inability to open and operate the SAR file does not necessarily mean that you do not have an appropriate software installed on your computer. There may be other problems that also block our ability to operate the SAR Compressed Format Archive (SAPCAR Archive) file. Below is a list of possible problems.
- Corruption of a SAR file which is being opened
- Incorrect links to the SAR file in registry entries.
- Accidental deletion of the description of the SAR from the Windows registry
- Incomplete installation of an application that supports the SAR format
- The SAR file which is being opened is infected with an undesirable malware.
- The computer does not have enough hardware resources to cope with the opening of the SAR file.
- Drivers of equipment used by the computer to open a SAR file are out of date.
If you are sure that all of these reasons do not exist in your case (or have already been eliminated), the SAR file should operate with your programs without any problem. If the problem with the SAR file has not been solved, it may be due to the fact that in this case there is also another rare problem with the SAR file. In this case, the only you can do is to ask for assistance of a professional staff.
Similar extensions
.a00 | Split Multi-volume ARJ Compressed File Archive (part 2) |
.a01 | Split Multi-volume ARJ Compressed File Archive (part 3) |
.a02 | Split Multi-volume ARJ Compressed File Archive (part 4) |
.ace | WinACE Compressed Ace Archive Format |
.alz | ALZip Compressed Format |
.ar | Linux/Unix Command Library Format |
.arc | ARC Lossless Data Compression And Archive Format |
.arj | ARJ Compressed Archive Format |
How to associate the file with an installed software?
If you want to associate a file with a new program (e.g. my-file.SAR) you have two ways to do it. The first and the easiest one is to right-click on the selected SAR file. From the drop-down menu select 'Choose default program', then click 'Browse' and find the desired program. The whole operation must be confirmed by clicking OK. The second and more difficult to do is associate the SAR file extension to the corresponding software in the Windows Registry.
Is there one way to open unknown files?
Many files contain only simple text data. It is possible that while opening unknown files (e.g. SAR) with a simple text editor like Windows Notepad will allow us to see some of the data encoded in the file. This method allows you to preview the contents of many files, but probably not in such a structure as a program dedicated to support them.