183

Is there such a thing? Absolutely. Feeding malicious input to a parser is one of the most common ways of creating an exploit (and, for a JPEG, "decompression" is "parsing"). Is this description based on some real exploit? It might be based on the Microsoft Windows GDI+ buffer overflow vulnerability: There is a buffer overflow vulnerability in the ...


88

First of all, that multi-encryption scheme is ridiculous. The algorithm used by 7-Zip is AES-256 which is considered secure. But if someone would find a flaw in it which would make it breakable, then they would likely be able to break all your encryption layers with equal effort. So either you trust the encryption algorithm used by 7-Zip, then one ...


53

Very good question. Yes, by default, WinRAR leaves traces of temporarily extracted files. WinRAR does indeed create temporary files when opening them directly from the archive. It also performs a normal deletion once WinRAR is closed. However, deleted files do physically stay on the disk after you delete them. Normal delete operations only delete the file ...


51

Agreeing with others to say yes this is totally possible, but also to add an interesting anecdote: Joshua Drake (@jduck), discovered a bug based on a very similar concept (images being interpreted by the OS) which ended up being named "Stagefright", and affected a ridiculous number of Android devices. He also discovered a similar image based bug in libpng ...


43

Though the article is not full of details, we can infer a few things: Attack uses compression with the same general principle as CRIME: the attacker can make a target system compress a sequence of characters which includes both a secret value (that the attacker tries to guess) and some characters that the attacker can choose. That's a chosen plaintext ...


38

This is over engineering on a scale I've never seen. This is a BAD THING ™ because it increases the complexity of your solution without adding any security benefit. The encryption mechanism is either safe, or it is not. You will not be more protected by encrypting multiple times. If the encryption is secure, it's useless to add additional layers of ...


26

Encryption hides data but leaks data size. That's a common property of all encryption systems: encrypted data has (more or less) the same size as the clear data. Compression alters the data size but it does so by finding "redundancies" (in a loose sense) in the data. So compression success rate depends on the data contents. Thus, compression makes data size ...


26

First off, breathe. Encryption efforts often fails if you forget to breathe. Something about going unconscious causes us to have a hard time encrypting things! Second, it sounds like you are in need of a threat model. A threat model describes what sort of adversaries you are worried about facing. Without a threat model, all security is security theater ...


16

I read that this should be avoided because of CRIME/BREACH attack, is this correct? It depends. The CRIME attack is already mitigated in current browsers in that they don't use TLS compression and have special handling of contexts in HTTP/2.0. BREACH is only relevant in the context of HTTP level compression if the following two conditions both apply at the ...


16

Encrypted data should be indistinguishable from random noise. Random data cannot be compressed. Therefore, compress data first and then encrypt it.


13

Encryption leaks data length: for any given input message, the encrypted output will have a length which will be close to that of the input message. If using a padding-less encryption mode (e.f. CFB, as used in the OpenPGP format that PGP implements), then the cleartext data length can be recovered exactly. This is a property common to all encryption systems,...


13

File compression utilities like Winrar or ZIP or 7zip encrypt the password and store it inside the archive. I don't know where you got this information (claims without source are always bad) but I'm sure you got it wrong. This would not make any sense and the question would also be which key would then be used to encrypt the password. With ZIP you can look ...


12

Unrealistic? There was recent critical bug in font definition parsing: https://technet.microsoft.com/en-us/library/security/ms15-078.aspx and libjpeg changenotes are full of security advisories. Parsing files[1] is hard: overflows, underflows, out of bounds access. Recently there were many fuzzing tools developed for semi-automatic detection of input that ...


12

No, what you are trying to accomplish is impossible. Encryption tries to keep information confidential. For this it takes one input message out of all possible input messages and encrypts in such a way that the output doesn't leak any information about the input message. Obviously you do not want that messages encrypt to the same output because in that case ...


10

Encrypting does not inherently make a file larger. However, in practice, encrypted files are larger than their non-encrypted counterparts for a number of reasons: Symmetric ciphers in current use have the property that every possible ciphertext can be decrypted to a plaintext, or in other words, if somebody tampers with the encrypted file, it can still be ...


10

support the new Brotli compression algorithm over HTTPS only. In theory yes. In practice Chrome will currently accept brotli compressed answers with plain HTTP too, even though it does not announce support for brotli in plain HTTP. Firefox only supports answers in HTTPS. If my understanding of BREACH (and the related CRIME attack) is correct, compression ...


9

BREACH, like CRIME, is a compression-related attack. Turning off compression makes the attack impossible. ADDED Note that in this case it appears that you turn off a different compression configuration; whereas CRIME exploits TLS-layer compression, BREACH exploits HTTP-layer compression.


9

How safe is it to decompress untrusted files Just looking at the CVE's for unzip you will find several possible code executions, modifying the permissions of existing files, overwriting arbitrary files outside the current directory.... The CVE list for unrar is shorter but includes also code execution. What steps can be taken to minimize the threat ...


9

Compression before encryption is a problem if the attacker can control parts of the transferred data and then use the detectable compression ratio (i.e. amount of transferred data vs. original data) to make conclusions about some of the traffic. This was in TLS used within BREACH and CRIME attacks to infer cookies and CSRF tokens. Making such attacks work ...


8

Ultimately, the CPU runs the code. And the CPU expects instructions in "clear text". You could envision some application code where a small initial part of the executable first decrypts the rest of the code, but this has several issues: This forces all the code to go to RAM instead of staying on disk and be loaded on-demand, implying a higher RAM ...


8

The recent compression-related attacks all work on the same principle: some chunk of bytes is compressed, containing both a data element that the attacker chooses, and a data element that the attacker wants to uncover. The resulting compressed length is used as a binary oracle in successive "guesses" from the attacker, who progressively rebuilds the secret ...


7

If an attacker can trick you into repeatedly encrypting (and consequently compressing) nearly the same plaintext over and over again, then I suspect that such an attack might be possible, but getting into those circumstances seems unlikely. (You'd need plaintext that combines something secret to the attacker and something attacker-controlled as well.) ...


7

The source of the "1032:1" figure is given on the zlib site where it is told that: The limit comes from the fact that one length/distance pair can represent at most 258 output bytes. A length requires at least one bit and a distance requires at least one bit, so two bits in can give 258 bytes out, or eight bits in give 1032 bytes out. A dynamic block has ...


6

This isn't possible/feasible, for two reasons. Compression doesn't "work" on random data - it won't actually significantly reduce the size of your data, and in fact, may increase the size. A one time pad must be greater than or equal in length to the data being encrypted. So if you're using the "remaining," unused part near the end of your one time pad to ...


6

CRIME and BREACH are attacks on the client. Their setup is that some hostile code is running in the client with limited capabilities (i.e. it is Javascript in a Web page). The attacker also controls the external traffic of the victim: he can inspect it, but also block it. This limits what the server actually sees. In both cases, the hostile Javascript will ...


6

I've been pondering this and I don't think your networking department is justified in this opinion. It does all depend on your threat model, but given the threat model of "hacked content to slip through the clients antivirus scanner", this opinion makes no sense. First, let's drop minification, because it's in plain text. There is no security reason or ...


6

The password is required to decrypt the archive, so storing a copy of the password inside the archive would be pointless - anyone who could decrypt the archive already has the password. The only things that get stored unencrypted in the archive are the encryption type, and perhaps the file structure and file attributes. Perhaps you're confused about how ...


5

RAR uses AES256 for encryptionsource, thus the question is whether AES is cryptographically resistant to a known-plaintext attack. At present there is no known method that allows retrieving AES encryption key given unlimited number of plaintext inputs and corresponding outputs faster than brute-force. Although there is no proof that it is impossible. See ...


Only top voted, non community-wiki answers of a minimum length are eligible