similar to: known plaintext attack

Hello Warren, On Thu, 2017-02-09 at 14:22 -0700, Warren Young wrote: > There are two serious problems with this argument: > > 1. Give me a scenario where this attacker can execute *only* pkcheck > in order to exploit this hypothetical library?s flaw, but where the > attacker cannot simply provide their own binary to do the same > exploit. Short of something insane like

On Thu, 2017-02-02 at 06:40 -0800, John R Pierce wrote: > On 2/2/2017 6:22 AM, Leonard den Ottolander wrote: > > However, the fact that the binary in the example is setuid is orthogonal > > to the fact that heap spraying is a very serious attack vector. > > without privilege escalation, what does it attack ? pkcheck might not be directly vulnerable. However, pkexec is.

We have discovered a potential Denial of Service / Amplification Attack in nbdkit. Lifecycle --------- Reported: 2019-09-11 Fixed: 2019-09-11 Published: 2019-09-12 There is no CVE number assigned for this issue yet, but the bug is being categorized and processed by Red Hat's security team which may result in a CVE being published later. Credit ------ Reported and patched by Richard W.M.

Hello, I saw that OpenSSH release 6.7 removed all CBC ciphers by default. Is CBC therefore considered as broken and unsecure (in general or SSH implementation)? I also read a lot of references (see below) but still not clear to me what's the actual "security status" of CBC and why it has been removed in general. http://www.openssh.com/txt/release-6.7 sshd(8): The default set

OpenSSH Security Advisory: cbc.adv Regarding the "Plaintext Recovery Attack Against SSH" reported as CPNI-957037[1]: The OpenSSH team has been made aware of an attack against the SSH protocol version 2 by researchers at the University of London. Unfortunately, due to the report lacking any detailed technical description of the attack and CPNI's unwillingness to share necessary

Hi, First, my thanks to Zed for including LiteSpeed in cgi.rb vulnerability report. Appreciated! I just got time to review ruby-lsapi code and test the vulnerability against LiteSpeed. I found that, in our latest ruby-lsapi release 1.11, lsapi_read() function returns Qnil when the end of request body has been reached. So, in theory, LiteSpeed should not be vulnerable to this attack. Our test

Hello. At work we collect logs (via ssh) from all kinds of hosts on one central node which has no connection to the internet and is tried to kept secure. The idea is, as you can imagine, that in case of a compromise we'd have at least all the logs up to the break without any forgeries. The logging is done continuously and compression is used. Now the following is not really that much

Based on an article that was mentioned on this list https://googleprojectzero.blogspot.nl/2014/08/the-poisoned-nul-byte-2014-edition.html I found two attacker controlled memory leaks in the option parsing of pkcheck.c. These memory leaks allow a local attacker the ability to "spray the heap", i.e. initialize large parts of the heap before launching his attack. The original attack

On Thu, 2017-02-02 at 13:40 -0800, Gordon Messmer wrote: > Escalation *requires* attacking a program in a security context other > than your own. Not necessarily. Suppose the adversary is aware of a root exploit/privilege escalation in a random library. Then the heap spraying allows this attacker to easily trigger this exploit because he is able to initialize the entire contents of the

Hi folks, Firstly; apologies in advance for what is a head wrecker of keeping on top of the speculative mitigations and also if this is a duplicate email; my first copy didn't seem to make it into the archive. Also a disclaimer that I may have misunderstood elements of the below but please bear with me. I write this hoping to find out a bit more about the state of the relevant kernel

You might find RedHat's CVE page on this useful: https://access.redhat.com/security/cve/cve-2023-48795 On Tue, Jan 23, 2024 at 10:04?AM Kaushal Shriyan <kaushalshriyan at gmail.com> wrote: > Hi, > > I have the SSH Terrapin Prefix Truncation Weakness on Red Hat Enterprise > Linux release 8.7 (Ootpa). The details are as follows. > > # rpm -qa | grep openssh >

We discovered a possible Downgrade Attack in libnbd. Lifecycle --------- Reported: 2019-09-14 Fixed: 2019-09-16 Published: 2019-09-16 There is no CVE number assigned for this issue yet, but the bug is being categorized and processed by Red Hat's security team which may result in a CVE being published later. Description ----------- Libnbd includes the method nbd_set_tls(h,

Hi, I have the SSH Terrapin Prefix Truncation Weakness on Red Hat Enterprise Linux release 8.7 (Ootpa). The details are as follows. # rpm -qa | grep openssh openssh-8.0p1-16.el8.x86_64 openssh-askpass-8.0p1-16.el8.x86_64 openssh-server-8.0p1-16.el8.x86_64 openssh-clients-8.0p1-16.el8.x86_64 # cat /etc/redhat-release Red Hat Enterprise Linux release 8.7 (Ootpa) # SSH Terrapin Prefix Truncation

My housemate has formalized a sortof new attack against unix-style operating systems. He''s a BSD fan, so that''s where he developed the attack. He asked me to check Linux, which I did. It seems Linux is not vulnerable to it. This attack is going out to BUGTRAQ tonight. The attack isn''t too serious because it requires physical access to the console, but it

Over the weekend one of our servers at a remote location was hammered by an IP originating in mainland China. This attack was only noteworthy in that it attempted to connect to our pop3 service. We have long had an IP throttle on ssh connections to discourage this sort of thing. But I had not considered the possibility that other services were equally at risk. Researching this on the web does

SSH.COM says their SSH2 is not vulnerable to the ZLIB problem even though they use the library (details below). Can OpenSSH say the same thing? In either case, it seems like there ought to be an openssh-unix-announce message about what the situation is. I may have missed it, but I don't believe there was one. Yes, openssh doesn't have its own copy of zlib source but it would still be

--------------------------------------------------------------------- Red Hat, Inc. Security Advisory Synopsis: Denial of service attack in in.telnetd Advisory ID: RHSA-1999:029-01 Issue date: 1999-08-19 Updated on: Keywords: telnet telnetd Cross references: --------------------------------------------------------------------- 1. Topic: A denial of service attack has been fixed in

The following is pasted from SecurityFocus Newsletter #254: ------------------------- Asterisk PBX Multiple Logging Format String Vulnerabilities BugTraq ID: 10569 Remote: Yes Date Published: Jun 18 2004 Relevant URL: http://www.securityfocus.com/bid/10569 Summary: It is reported that Asterisk is susceptible to format string vulnerabilities in its logging functions. An attacker may use these

CORE SDI http://www.core-sdi.com SSH1 CRC-32 compensation attack detector vulnerability Date Published: 2001-02-08 Advisory ID: CORE-20010207 Bugtraq ID: 2347 CVE CAN: CAN-2001-0144 Title: SSH1 CRC-32 compensation attack detector vulnerability Class: Boundary Error Condition Remotely Exploitable: Yes Locally Exploitable: Yes Release Mode:

On Fri, 6 Dec 2019 at 04:40, Kenneth Porter <shiva at sewingwitch.com> wrote: > > <https://www.bleepingcomputer.com/news/security/new-linux-vulnerability-lets-attackers-hijack-vpn-connections/> > Thanks for the heads up > This affects all VPNs and is a consequence of using "loose" reverse path > filtering for anti-spoofing. The default CentOS setting is