similar to: can compression be safely used with SSH?

Also nice to know that zlib at openssh.com enables the compression only after authentication, mitigating the known problems with compression and passwords. It is also very hard to do chosen-plaintext attacks on the client to server side (in opposite to HTTPS where that's trivial). And most passwords that are typed after authentications are entered character by character, making them fall under

On Sat, 22 Nov 2014, Philippe Cerfon wrote: > Hello. > > >Even if delayed compression is only activated after authentication, > >the the fact that delayed compression will be used has already been > >negotiated before authentication and can't be changed retroactively. > > Couldn't the server simply abort a connection in the case that it sees > that the

I see. From reading that wikipedia article, I'm wondering what gets compressed when compression is enabled in openssh. Is it the ciphertext or the cleartext? Regards, Mark On Fri, 2013-10-25 at 15:47 -0400, Daniel Kahn Gillmor wrote: > On 10/25/2013 03:23 PM, Mark E. Lee wrote: > > Thanks for the response, what kind of problematic interactions would > > occur (other than

https://bugzilla.mindrot.org/show_bug.cgi?id=2322 Bug ID: 2322 Summary: please let the server enable/disable delayed compression on a per user basis Product: Portable OpenSSH Version: 3.7p1 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5

We have a system on which users are given a very restricted environment (their shell is a menu) where they should not be able to run arbitrary commands. However, because their shell is not statically linked, ld.so provides a nice clutch of holes for them to exploit. The patch below adds a new configuration option to sshd which quashes their attempts to set LD_PRELOAD etc. using ~/.ssh/environment

Compression has some problematic interactions with encryption that OpenSSH seems to have handled far before anyone else (by having it off by default). On Thursday, October 24, 2013, Darren Tucker wrote: > On Thu, Oct 24, 2013 at 07:30:38PM -0400, Mark E. Lee wrote: > > I'm a long time user of openssh and I was wondering if there is any work > > towards supporting alternative

Hello, Our "it-security" department asked me about Qualys warnings like -> SSL/TLS Compression Algorithm Information Leakage Vulnerability As far as I learned it's compression inside ssl. postfix-2.11 knows 'tls_ssl_options = no_compression' ( see http://www.postfix.org/postconf.5.html#tls_ssl_options ) is the something comparable in dovecot too? Looks like most

Compressing data before encryption may be dangerous, for example CRIME, BREACH and VORACLE. Can compression be disabled by default in OpenSSH, only being enabled if user requests it? Another scenario when SSH compression may be bad is use of commands like tar cz | ssh root at remote "tar xz", which seem pretty common. If SSH compression is enabled, data will be (wastefully) compressed

For the encryption functionality in the ZFS filesystem we use AES in CCM or GCM mode at the block level to provide confidentiality and authentication. There is also a SHA256 checksum per block (of the ciphertext) that forms a Merkle tree of all the blocks in the pool. Note that I have to store the full IV in the block. A block here is a ZFS block which is any power of two from 512 bytes to

I think there is nothing FreeBSD can do about this besides making sure our users are aware of it. The situation in which this is a problem is specific but one you should consider if you are using TLS with compression. TLS 1.2 and earlier are vulnerable to an attack commonly known as CRIME. The attack involves TLS sessions using compression where an attacker is able to inject known plaintext into

Hey. I've noticed the following behavior and wondered whether it's possibly a bug or why it behaves like this: When having a SSH connection, than it seems there may be two sshd processes for that, one running as root the other as the user. As far as I know this is because of privilege separation, like e.g.: ??sshd(2931)???sshd(10174)???bash(10180) ?

On Thu, 29 Dec 2022, Philippe Cerfon wrote: > Hey. > > On Thu, Dec 29, 2022 at 1:28 AM Damien Miller <djm at mindrot.org> wrote: > > It's because the monitor process doesn't explicitly handle SIGQUIT. > > Are you going to merge the patch of yours? Does it solve your problem? -d

Open-Xchange Security Advisory 2021-06-21 Product: Dovecot Vendor: OX Software GmbH Internal reference: DOV-4583 (Bug ID) Vulnerability type: CWE-74: Failure to Sanitize Data into a Different Plane ('Injection') Vulnerable version: 2.3.0-2.3.14 Vulnerable component: submission Report confidence: Confirmed Solution status: Fixed by Vendor Fixed version: 2.3.14.1 Vendor notification:

Open-Xchange Security Advisory 2021-06-21 Product: Dovecot Vendor: OX Software GmbH Internal reference: DOV-4583 (Bug ID) Vulnerability type: CWE-74: Failure to Sanitize Data into a Different Plane ('Injection') Vulnerable version: 2.3.0-2.3.14 Vulnerable component: submission Report confidence: Confirmed Solution status: Fixed by Vendor Fixed version: 2.3.14.1 Vendor notification:

Hi, sorry if it is the wrong approuch to suggest improvments to OpenSSH, but here comes my suggestion: I recently stumbled upon the scponly shell which in it's chroot:ed form is an ideal solution when you want to share some files with people you trust more or less. The problem is, if you use the scponlyc as shell, port forwarding is still allowed. This can of course be dissallowed in

Why are legacy MACs (like md5-96), and legacy Ciphers (anything in cbc-mode, arcfour*(?)) enabled by default? My proposal would be to change the defaults for ssh_config and sshd_config to contain: MACs hmac-sha2-256,hmac-sha2-512,hmac-sha1 Ciphers aes128-ctr,aes192-ctr,aes256-ctr ...removing md5, truncated versions of sha1, umac64 (for which I can find barely any review), any cipher in cbc

Hi, Some of you have heard of CRIME, probably. from https://bugzilla.redhat.com/show_bug.cgi?id=857051 > Adding the following line to the /etc/sysconfig/httpd file: > > export OPENSSL_NO_DEFAULT_ZLIB=1 But there are other services but http that use ssl and are vulnerable? What is the optimal place for setting this environment variable system wide? I tried to set it in

Hey. On Thu, Dec 29, 2022 at 1:28 AM Damien Miller <djm at mindrot.org> wrote: > It's because the monitor process doesn't explicitly handle SIGQUIT. Are you going to merge the patch of yours? Best wishes, Philippe.

On Tue, Jan 21, 2020 at 11:08:51AM +1100, Damien Miller wrote: > So IMO disallowing session multiplexing is at most a speedbump that an > attacker will cross with relative ease. Speedbumps make sense sometimes, An attacker getting root on the jumphost gets immediate control of any _current_ persistent connections and new connections. Without ControlMaster it's a _lot_ harder to take

The following is a patch I've been working on to support a "ChrootUser" option in the sshd_config file. I was looking for a way to offer sftp access and at the same time restict interactive shell access. This patch is a necessary first step (IMO). It applies clean with 'patch -l'. Also attached is a shell script that helps to build a chrooted home dir on a RedHat 7.2