{{Header}}
{{#seo:
|description=Security and Privacy Risks Posed by Core Dumps
|image=Coredumps.png
}}
[[image:Coredumps.png|200px|thumb]]
{{intro|
Security and Privacy Risks Posed by Core Dumps
}}
= Introduction =

All operating systems have a "core dump" functionality which poses potential security and privacy risks. According to Wikipedia: <ref name=Core_dump>https://en.wikipedia.org/wiki/Core_dump</ref>

<blockquote>In computing, a core dump (in Unix parlance), memory dump, or system dump consists of the recorded state of the working memory of a computer program at a specific time, generally when the program has crashed or otherwise terminated abnormally. In practice, other key pieces of program state are usually dumped at the same time, including the processor registers, which may include the program counter and stack pointer, memory management information, and other processor and operating system flags and information. Core dumps are often used to assist in diagnosing and debugging errors in computer programs.</blockquote>

The primary function of core dumps is to provide the user or programmer with specialized information to determine the root cause of a system crash, in order to perform debugging. These files are viewable as text or image formats, and can be analyzed with special tools. In Windows, both kernel-mode dumps and user-mode dumps are available. The former contains information on either the full memory or large sections of it, while the latter is limited to single processes. <ref name=Core_dump />

= Security and Privacy Risks =

{{mbox
| image   = [[File:Ambox_warning_pn.svg.png|40px]]
| text    = Most of today’s operating systems, libraries, languages, and so on leave sensitive data they handle -- passwords, financial and other information -- scattered throughout memory, and it often leaks to disk. Information may be left there for an indeterminate period and this increases the risk of a system compromise. <ref name=Core_dump2>https://cs.stanford.edu/people/jchow/papers/lifetime-sigops04.pdf</ref>
}}

Core dumps can potentially contain sensitive information like: <ref>https://wiki.archlinux.org/title/Core_dump</ref> <ref name=Core_dump2 /> <ref>https://security.stackexchange.com/questions/131552/risks-of-encryption-keys-contained-in-a-memory-dump-after-a-crash</ref>

* Any activities undertaken in a session.
* All existing contents in RAM at the time of a crash:
** Disk encryption keys and passwords.
** Details of open documents.
** Other passwords.
** Detailed system information that can assist targeted attacks.

Clearly, how long copies of data survive and where they end up are critical factors. There is no guarantee that RAM is wiped or overwritten during this process. This is not just a theoretical concern, as exploits in the wild have been observed which force privileged applications to perform core dumps, disclosing the contents of shadow password files and other information in the process. <ref name=Core_dump2 />

While this information is stored locally on GNU/Linux distributions, this is not the case on proprietary platforms. Windows and macOS generally ship this memory information to the operating systems vendor. <ref name=Core_dump2 /> <ref>https://docs.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps?redirectedfrom=MSDN</ref> <ref>https://en.wikipedia.org/wiki/Crash_Reporter</ref> <ref>https://www.networkworld.com/article/2164903/windows-how-to-solve-windows-8-crashes-in-less-than-a-minute.html</ref> <ref>Notably, GNU/Linux platforms like Debian usually have core dump functionality turned on via systemd's default settings.</ref>

= Disabling Core Dumps =
Core Dumps are disabled by default in {{project_name_long}}.

<u>If using a {{VM}}...</u>

For greater security, advanced users should consider configuring the host operating systems to disable core dumps. If possible, preventing access to process memory is also advisable, along with secure storage of the file system. <ref>
https://docs.tibco.com/pub/rendezvous/8.3.1_january_2011/html/tib_rv_administration/rv_adm.6.072.htm ([https://archive.ph/OeJvZ archive.ph])
</ref> <ref>
https://stackoverflow.com/questions/17068818/how-to-deal-with-passwords-securely-within-your-application
</ref> GNU/Linux users can further research the disabling of core dump features [https://linux-audit.com/understand-and-configure-core-dumps-work-on-linux/ here] and [https://wiki.archlinux.org/title/Core_dump here]. Debian users should refer to the manpages concerning [https://manpages.debian.org/stable/systemd-coredump/coredump.conf.5.en.html core dump storage configuration files]. In general, Linux normally requires: <ref>https://linux-audit.com/understand-and-configure-core-dumps-work-on-linux/#disable-core-dumps</ref>

* Setting a ulimit value via a configuration file; or
* Configuring ulimit via a profile (custom) file; or
* Setting nil storage in the systemd coredump configuration file.

It is also recommended to [https://linux-audit.com/understand-and-configure-core-dumps-work-on-linux/#disable-setuid-processes-dumping-their-memory disable setuid processes from dumping their memory], since processes with elevated permissions might otherwise still perform core dumps. <ref>
Processes with greater access might also have more sensitive data elements in memory.
</ref> For greater safety, [https://linux-audit.com/understand-and-configure-core-dumps-work-on-linux/#testing-your-configuration test the configuration] works correctly.

= Enabling Core Dumps =
To enable core dumps in {{project_name_short}} follow the following steps.

The [[debug-misc]] package is the simplest solution to enable core dumps. For better security, this package should only be installed on specific machines that require debugging. Unfortunately, security and debugging are conflicting optimization goals.

{{Install Package|
package=debug-misc
}}

= References =
{{reflist|close=1}}

{{Footer}}

[[Category:Documentation]]