Re: Bug#1098775: bullseye-pu: package proftpd-dfsg/1.3.7a+dfsg-12+deb11u4
On Sun, 2025-02-23 at 23:45 +0100, Hilmar Preusse wrote: > The patch solves an annoying issue: > > Proftpd does use the same server port for multiple passive FTP > connections. > Even when executing multiple simultaneous FTP sessions from different > clients. This does break simultaneous passive FTP connections, file > listings and transfers. bullseye is no longer maintained by the Release Team, but by the LTS Team (CCed). Please co-ordinate with them regarding any possible update in bullseye. Regards, Adam
unsubsrcibe
— Valentin Staubmann https://staubmann.eu +43 660 8707699 I prefer using signed emails. My public PGP key fingerprint is 430F 0145 F479 CB44 C3EC 55D5 4EBB FCCB 5305 D0B2 > Am 24.02.2025 um 00:22 schrieb Daniel Leidert : > > - > Debian LTS Advisory DLA-4066-1debian-lts@lists.debian.org > https://www.debian.org/lts/security/ Daniel Leidert > February 24, 2025 https://wiki.debian.org/LTS > - > > Package: fort-validator > Version: 1.5.3-1~deb11u2 > CVE ID : CVE-2024-45234 CVE-2024-45235 CVE-2024-45236 CVE-2024-45237 > CVE-2024-45238 CVE-2024-45239 CVE-2024-48943 > > Multiple vulnerabilities have been discovered in fort-validator, a RPKI > validator and RTR server. > > CVE-2024-45234 > > A malicious RPKI repository that descends from a (trusted) Trust > Anchor can serve (via rsync or RRDP) an ROA or a Manifest containing > a signedAttrs encoded in non-canonical form. This bypasses Fort's > BER decoder, reaching a point in the code that panics when faced > with data not encoded in DER. Because Fort is an RPKI Relying Party, > a panic can lead to Route Origin Validation unavailability, which > can lead to compromised routing. > > > CVE-2024-45235 > > A malicious RPKI repository that descends from a (trusted) Trust > Anchor can serve (via rsync or RRDP) a resource certificate > containing an Authority Key Identifier extension that lacks the > keyIdentifier field. Fort references this pointer without sanitizing > it first. Because Fort is an RPKI Relying Party, a crash can lead to > Route Origin Validation unavailability, which can lead to > compromised routing. > > CVE-2024-45236 > > A malicious RPKI repository that descends from a (trusted) Trust > Anchor can serve (via rsync or RRDP) a signed object containing an > empty signedAttributes field. Fort accesses the set's elements > without sanitizing it first. Because Fort is an RPKI Relying Party, > a crash can lead to Route Origin Validation unavailability, which > can lead to compromised routing. > > CVE-2024-45237 > > A malicious RPKI repository that descends from a (trusted) Trust > Anchor can serve (via rsync or RRDP) a resource certificate > containing a Key Usage extension composed of more than two bytes of > data. Fort writes this string into a 2-byte buffer without properly > sanitizing its length, leading to a buffer overflow. > > CVE-2024-45238 > > A malicious RPKI repository that descends from a (trusted) Trust > Anchor can serve (via rsync or RRDP) a resource certificate > containing a bit string that doesn't properly decode into a Subject > Public Key. OpenSSL does not report this problem during parsing, and > when compiled with OpenSSL libcrypto versions below 3, Fort > recklessly dereferences the pointer. Because Fort is an RPKI Relying > Party, a crash can lead to Route Origin Validation unavailability, > which can lead to compromised routing. > > CVE-2024-45239 > > A malicious RPKI repository that descends from a (trusted) Trust > Anchor can serve (via rsync or RRDP) an ROA or a Manifest containing > a null eContent field. Fort dereferences the pointer without > sanitizing it first. Because Fort is an RPKI Relying Party, a crash > can lead to Route Origin Validation unavailability, which can lead > to compromised routing. > > CVE-2024-48943 > > A malicious RPKI rsync repository can prevent Fort from finishing > its validation run by drip-feeding its content. The delayed > validation can lead to stale or unavailable Route Origin Validation. > > For Debian 11 bullseye, these problems have been fixed in version > 1.5.3-1~deb11u2. > > We recommend that you upgrade your fort-validator packages. > > For the detailed security status of fort-validator please refer to > its security tracker page at: > https://security-tracker.debian.org/tracker/fort-validator > > Further information about Debian LTS security advisories, how to apply > these updates to your system and frequently asked questions can be > found at: https://wiki.debian.org/LTS > signature.asc Description: Message signed with OpenPGP
Regression in DLA 4053-1 - freerdp2
I've got report that there is a regression introduced by 2.3.0+dfsg1-2+deb11u2. The issue is related to drive sharing and is reported to not working anymore. The reporter analysed the issue as: > Drive sharing does not work for us any longer using version > 2.3.0+dfsg1-2+deb11u2, but it works using 2.3.0+dfsg1-2+deb11u1 or > 2.10.0+dfsg1-1~bpo11+1 > > In debian/patches/0057-CVE-2022-41877.patch the following define is included, > which is not found in upstream (as in newer versions a real function is > defined). > +#define Stream_CheckAndLogRequiredLength(tag, s, len) > \ > + Stream_CheckAndLogRequiredLengthWLogEx(WLog_Get(tag), WLOG_WARN, s, > len, "%s(%s:%" PRIuz ")", __FUNCTION__, \ > + __FILE__, __LINE__) > > The function Stream_CheckAndLogRequiredLengthWLogEx is defined in > winpr/libwinpr/utils/stream.c: > BOOL Stream_CheckAndLogRequiredLengthWLogEx(wLog* log, DWORD level, wStream* > s, size_t nmemb, >size_t size, const char* fmt, ...) > > I think the define missed passing on the parameter for 'size', which I guess > should be 1, from reading upstream sources. > This leads to error messages like > [drive_process_irp_query_directory] invalid length, got 0, require at > least 6 [element size=140103248640086] I will look into the issue ASAP. -- tobi signature.asc Description: PGP signature
