Movatterモバイル変換

[0]ホーム
URL:

Home page logo
oss-sec logo

Open Source Security Mailing List

Discussion of security flaws, concepts, and practices in the Open Source community

List Archives

Latest Posts

Re: MIT/Heimdal Kerberos credentials cache type FILE risksRuss Allbery (Feb 19)
Jacob Bachmeyer <jcb62281 () gmail com> writes:

That requires Kerberos support in the client, which is notoriously not
always available (mobile clients, for instance, often do not have Kerberos
clients). It's been a problem in the mail world for a long time that we
have a ton of better authentication protocols than PLAIN but a lot of mail
clients still like using PLAIN, to such an extent that we have things like
device-specific...

Re: MIT/Heimdal Kerberos credentials cache type FILE risksJacob Bachmeyer (Feb 19)
I would that think in such a scenario, the client should be presenting a
Kerberos service ticket to the POP/IMAP server.

If PAM is creating the ticket cache when the session is opened, then PAM
should also be destroying the ticket cache when the session is closed.

If the server is opening PAM sessions, but never closing them, then that
is a bug in the server, not Kerberos.

I was thinking that it also depends on when the service last renewed...

Re: MIT/Heimdal Kerberos credentials cache type FILE risksJacob Bachmeyer (Feb 19)
Excellent, someone with more and/or more-recent knowledge on the topic!  :-)

That is an interesting way of looking at it.  The report seemed to me to
be describing hijacking user accounts after cracking a service.  I agree
that this is a greater risk for services, but also that those risks are
well-known, and I add that a service should have much narrower access
than a user.

Exactly.  The risks here are already well-known; the report is...

Re: MIT/Heimdal Kerberos credentials cache type FILE risksRuss Allbery (Feb 19)
Jacob Bachmeyer <jcb62281 () gmail com> writes:

That's also possible for services that accept usernames and passwords and
validate them with Kerberos (common for POP and IMAP servers), although of
course best practices in those cases is to immediately discard the
resulting ticket after authentication.

It is true that some methods of doing that will result in a ticket cache
stored in /tmp. For example, if the service uses PAM to...

Re: MIT/Heimdal Kerberos credentials cache type FILE risksRuss Allbery (Feb 19)
It's been some years since I've worked on Kerberos extensively, but I
still maintain some Kerberos-related software and may be able to provide
some context here. I have not been closely tracking developments in
keyring formats and do not know how usable KEYRING caches are these days,
so I may get some of these details wrong.

Jacob Bachmeyer <jcb62281 () gmail com> writes:

My understanding is that the context of this report is...

Re: MIT/Heimdal Kerberos credentials cache type FILE risksJacob Bachmeyer (Feb 19)
That would be the first warning sign.

And this would be a second strike.

My summary up front:  this report is bogus.

I would not be so sure about FILE being unsafe at all.

While I cannot claim to be an expert on Kerberos, I did once seriously
evaluate deploying Kerberos telnet for server administration at a
previous $WORK, so I do know some aspects of the system.

Which process lifetime are we talking about here?  The kinit command
that...

Re: Default IV & other issues in aes-js & pyaes modules, & strongMan VPN managerSoatok Dreamseeker (Feb 19)
Hi Alan,

That strongMan patch is refreshing to see:

The latest version fixes the issue by switching to AES-GCM-SIV encryption

The patch is also pretty small:

diff --git a/requirements.txt b/requirements.txt
index 6cf1caa..111fa76 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -1,6 +1,7 @@
Django==4.2.28
git+https://github.com/wbond/oscrypto.git@1547f535001ba568b239b8797465536759c742a3
asn1crypto==1.5.1
+cryptography==46.0.3...

Default IV & other issues in aes-js & pyaes modules, & strongMan VPN managerAlan Coopersmith (Feb 19)
https://blog.trailofbits.com/2026/02/18/carelessness-versus-craftsmanship-in-cryptography/
reports:

[...]

[...]

[...]

[...]

[...]

See the full original blog post for further details and some strong opinions
omitted above.

For the strongMan issue, see:
https://github.com/strongswan/strongMan/security/advisories/GHSA-88w4-jv97-c8xr

Re: Systemd vsock sshdSolar Designer (Feb 18)
Brad Spengler pointed me at this Linux merge commit (it's not in 6.19,
should get into 6.20):

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=099ca4121ea747acc8a0d36852f2f477943f306d

commit 099ca4121ea747acc8a0d36852f2f477943f306d
Merge: 3eef6c061f97 b3b7b33264c6
Author: Paolo Abeni <pabeni () redhat com>
Date: Tue Jan 27 10:45:40 2026 +0100

Merge branch...

MIT/Heimdal Kerberos credentials cache type FILE risksSolar Designer (Feb 18)
Hi,

Raul Vega, CC'ed here, sent the below AI-generated message to
linux-distros on Feb 5, without disclosing the use of AI, yet correctly
set the public disclosure date to "2026-02-18 (14-day embargo per
linux-distros policy)" (or maybe the AI assistant did). Unfortunately,
there was no further correspondence (in particular, I got no reply to my
reply, also included below), and Raul failed to bring this to
oss-security on time on...

Re: Re: zlib security audit by 7asecuritySevan Janiyan (Feb 18)
I did some more digging and found that on OS X 10.6 (from 2009) and
prior vsnprintf() is not used because of the discrepancy in gzguts.h,
though configure is happy.
On OS X 10.7 (from 2011) onwards you're good if you stick to the default
compiler which is clang.
If you switch to the fallback secondary compiler (llvm-gcc 4.2) then
you'll have the same issue as OS X 10.6 and prior, when building on OS X
10.7 & 10.8 (from 2012)....

CVE-2026-23552: Apache Camel: Camel-Keycloak: Cross-Realm Token Acceptance Bypass in KeycloakSecurityPolicyAndrea Cosentino (Feb 18)
Severity: important

Affected versions:

- Apache Camel (org.apache.camel:camel-keycloak) 4.15.0 before 4.18.0

Description:

Cross-Realm Token Acceptance Bypass in KeycloakSecurityPolicy Apache Camel Keycloak component.

This issue affects Apache Camel: from 4.15.0 before 4.18.0.

Users are recommended to upgrade to version 4.18.0, which fixes the issue.

This issue is being tracked as CAMEL-22854

Credit:

Andrea Cosentino (finder)
Andrea...

CVE-2026-25747: Apache Camel: Deserialization of Untrusted Data in Camel LevelDBAndrea Cosentino (Feb 18)
Severity: important

Affected versions:

- Apache Camel (org.apache.camel:camel-leveldb) 4.10.0 before 4.10.9
- Apache Camel (org.apache.camel:camel-leveldb) 4.14.0 before 4.14.5
- Apache Camel (org.apache.camel:camel-leveldb) 4.15.0 before 4.18.0

Description:

Deserialization of Untrusted Data vulnerability in Apache Camel LevelDB component.

This issue affects Apache Camel: from 4.10.0 before 4.10.8, from 4.14.0 before 4.14.5, from 4.15.0...

Re: Re: zlib security audit by 7asecuritySevan Janiyan (Feb 18)
Dug in a bit further and realised the logic in gzguts.h makes the wrong
assumption about "if C89/90, assume no C99 snprintf() or vsnprintf()" as
these functions have been around for a very long time[1] though
formalised in C99. All versions of OS X include it and you are likely
going to be building with a compiler that only supports C89/90 on the
earlier releases or defaults to it.

Raised a pull request[2], let's see if it...

Multiple vulnerabilities in JenkinsDaniel Beck (Feb 18)
Jenkins is an open source automation server which enables developers around
the world to reliably build, test, and deploy their software.

The following releases contain fixes for security vulnerabilities:

* Jenkins 2.551
* Jenkins LTS 2.541.2

Summaries of the vulnerabilities are below. More details, severity, and
attribution can be found here:
https://www.jenkins.io/security/advisory/2026-02-18/

We provide advance notification for security...

More Lists

Dozens of other network security lists are archived atSecLists.Org.

[8]ページ先頭
©2009-2026 Movatter.jp