15

As a software developer, should my crash dumps (e.g. from Breakpad, Windows) be encrypted and signed? I provide the ability to export crash dumps so that I can pinpoint the problem when the user reports one.

My concerns, in terms of protecting my product (the attacker is a user hacking the product to gain something):

  • Dumps give too much info for hackers to reverse engineer or hack the software, say to enable features or licenses?
  • Passwords and keys might be stored in the dumps for hackers to hack the software.
  • A user could return us a maliciously malformed dump, which causes havoc when we try to decipher the dump on our machines. If our application signs the dump, at least we can confidently open the file.

Update: For the last bullet point, one of the answers has reminded me that there is no pointing in signing the data, since the key has to be in the product itself, which the hacker can then use it to sign anyway. Furthermore, the fear of malicious dumps can be circumvented through the use of temporary virtual machines.

The last remaining concern is how dumps, given it contains addresses and stuff, could help hackers circumvent restrictions like licensed features.

Improve this question
9
  • 18
    So you think the attacker is sophisticated and motivated enough to create a malicious dump, but not sophisticated and motivated enough to extract your key from the binary and encrypt+sign it themself?
    – Steve Sether
    Jun 5, 2018 at 12:56
  • 2
    Question: are you trying to protect against an attacker hacking you, or hacking the user? They're two very different questions (although with some overlapping defense measures), so knowing which one you're talking about is useful.
    – Soron
    Jun 5, 2018 at 15:09
  • @EthanKaminski, I'm trying to protect my product (user hacking the product to gain something), so I guess that's "hacking me"?
    – Ryuu
    Jun 5, 2018 at 17:46
  • 2
    @Ryuu if you worry that an attacker will send you an malicious dump, the simplest way to mitigate this would be to isolate the environment where you open your dump. Virtualization is a perfect fit for such isolation.
    – vidarlo
    Jun 5, 2018 at 18:11
  • 1
    An application crash can create an accidentally malformed dump that can cause just as much havoc as a maliciously malformed dump. If you're not protecting yourself against the possibility that a dump is malformed, you're doing something wrong.
    – Mark
    Jun 5, 2018 at 23:09

3 Answers 3

Reset to default
29

Dumps give too much info for hackers to reverse engineer or hack the software, say to enable features or licenses?

The dumps must, at some point, exist in unencrypted form. An attacker with full local control can either grab the dumps at that instant - or simply ignore them, and look at the memory of the running application at will.

Some programs, such as spotify, try to detect if they are running in a debugging environment, and use various obfuscation schemes to slow down reverse engineering. This may thwart un-experienced attackers, or slow down experienced ones. But it will probably not stop an attacker. This is basically the reason why companies like Microsoft opt for online license validation.

However, encryption in transit is an entirely different matter. Protecting customers assets that may be available in a dump, or even licenses installed on a customers computer, makes this a good proposition - ensuring that no third party can get access to the dump.

It's also easy to implement; submit the dump over for instance https. While the gain from this may be small, depending on the content of the dumps, it's also very cheap to implement, and reduces the risks to both yours and the customers data. Remember that your customer probably values their data more than they value your product.

A user could return us a maliciously malformed dump, which causes havoc when we try to decipher the dump on our machines. If our application signs the dump, at least we can confidently open the file.

To sign the files, the application has to access a private key. The private key has to be present in memory on the machine doing the signing at some stage. It has to be distributed with every instance of the software.

An attacker can access the key and sign his malicious dump file.

It will not help against using the dumps as an attack vector.

Improve this answer
9
  • It is safe to say that if I want to enable crash dumps in my application, we then have to expect that users will be able to read it, but there is no harm as there is no sensitive information involved, other than just call stacks and addreses?
    – Ryuu
    Jun 5, 2018 at 14:34
  • 11
    The user is free to peek at the memory of his own computer. You can try to obfuscate how the memory is used, but you can never assume any privacy when the application is running on another persons computer. What data the dump contains depends on what data it contains.
    – vidarlo
    Jun 5, 2018 at 14:37
  • 1
    The paragraph about encryption in transit sounds like it's more focused on protecting against attacks against the user, rather than against the product. I agree that it's objectively a good thing to do so, but given that the question seems to be about protecting the product (see comments added since you answered), it seems worthwhile to explain/signpost why also protecting user information is good.
    – Soron
    Jun 5, 2018 at 17:54
  • 1
    @supercat the client can still access the key in memory.
    – vidarlo
    Jun 6, 2018 at 6:11
  • 2
    @supercat if it's running on a server many of the worries in the original post is void anyway.
    – vidarlo
    Jun 6, 2018 at 14:48
5

[...] should my crash dumps [...] be encrypted and signed?

Someone can create any number of crash dumps with various tools like Task Manager, Process Explorer, ProcDump, WinDbg, Visual Studio, DebugDiag, WER, AdPlus (and potentially more) and you have no chance of intercepting those. An attacker would not use your encrypted Breakpad crash dump but create his own regular crash dumps instead.

However, you should make sure to comply with privacy regulations and make sure that only authorized personell can access the crash dumps. In that case, encryption might help, but any other access control is also fine.

Dumps give too much info for hackers to reverse engineer or hack the software, say to enable features or licenses?

A live instance of the application gives even more info. Just think like this: you can create many crash dumps, thus you have more information to analyze.

Also: did you know that you can influence the size of the crash dump? Depending on the MINIDUMP_TYPE options, the crash dump contains more or less information.

A user could return us a maliciously malformed dump, which causes havoc when we try to decipher the dump on our machines.

Of yourse possible, but unlikely. It would be a security related bug in the debugger as possible in any other application. The debugger will just read the information from the crash dump, not execute it.

How does the attacker send you a crash dump without identifying himself?

Improve this answer
2
  • Good point regarding privacy regulations. Do you know of any standard regulations that software producers need to comply? I checked our EULA and didn't find anything ... next would be to visit Legal and ask.
    – Ryuu
    Jun 6, 2018 at 10:10
  • 1
    @Ryuu: I have read the regulations that Microsoft applies to the Windows Error Reporting (WER) system, which sends crash dumps to Microsoft where you can download them. However, it did not consider local regulations, such as the new GDPR in Europe (DSGVO in Germany). In that NDA, you declared that you securely erase (special tools needed such as SDelete) crash dumps immediately when not needed any longer but after 6 weeks latest (whether or not you solved the issue). Many crash dumps contain personal information (e.g. user names, directories, logon info in the PEB (environment variables))
    – Thomas Weller
    Jun 6, 2018 at 10:26
3

My personal view is it will depend on the cost / benefit to you.

Digital sign the files yes. It will reduce work and allows you to receive dumps from your real customers. For the transport of information yes. You should use an encrypted channel and if not possible them encrypt the data. I believe it is easier to deliver it using https for example instead of trying to implement some method of encryption on the data that can fail.

Locally it will depend on the landscape.

Normally dumps should not be allowed by default and should be enabled only for troubleshooting specific issues on production servers.

When enabled, it is advisable to configure a specific partition for dumps and for that partition to be allowed access to privileged users, and never leave the dump data in rest at the system, as soon it is generated it should be moved from production environment for the analysis.

In This situations it is a controlled thing, and implementing encryption here will not add any real benefit.

If you have some type of automation that generates dumps and delivers them to your organization then I would say yes you MUST implement encryption everywhere specially if the dump might have PII data... Dumps at rest that have not been deleted or overwritten are a good source of information about what is running on the server.

That is not a best practice as Production servers should have DUMPS disabled and DEBUG also disabled. This should be enabled only when required and with some sysadmin monitoring it live.

Encryption will bring some challenges that will cost you money.

PKI infra: If you own the private key then none of your customers will be allowed to access the data locally unless you share the key.

If you wish to allow your customers to have the private key to access their local dump then you will enter in a key management issues that can be time consuming as you will have to generate a private key per customer.

Revoking a key will require application update in all your customers...

Synchronous key: Does not makes much sense as the key will have to exist somewhere in the system to allow encryption of the data.

Changing key will also be a challenge and time consuming.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .