similar to: Dovecot & gethostbyname() vulnerability

[Mod: I am approving this message even though it is just a rehash of known vulnerabilities of DNS. Please in future lets avoid rehashing what was alreadt discussed in probably every single mailing list that deals with UNIX security several years ago? -- alex ] ###### ## ## ###### ## ### ## ## ######

> Ok, I've just checked doing the same thing under windows. > > The test(ripdaveno is the name of the Computer I tested on): > > { > ... > hostent* h = gethostbyname("ripdaveno"); > char* str = inet_ntoa(*((in_addr*)h->h_addr_list[0])); > ... > } > > The string in str was "192.168.2.75" which is my Network IP-Adress. With >

Saw this on the Exim List:- From: Tony Finch <dot--at-- at dotat.at> Subject: [exim] CVE-2015-0235 - glibc gethostbyname remotely exploitable via exim Date: Tue, 27 Jan 2015 17:33:45 +0000 "The Exim mail server is exploitable remotely if configured to perform extra security checks on the HELO and EHLO commands ("helo_verify_hosts" or "helo_try_verify_hosts"

Hi, Lately, the system log on my CentOS 5 box, with all the latest updates, have started filling up with messages of the form: Jan 24 09:47:26 i58524 rpc.statd[3452]: gethostbyname error for i58524 Jan 24 09:47:26 i58524 rpc.statd[3452]: STAT_FAIL to i58524 for SM_MON of 10.30.39.59 Jan 24 09:47:26 i58524 kernel: lockd: cannot monitor 10.30.39.59 It does not seem like there is really anything

I reported a bug recently to the debian bug tracking system but I just checked this mailing list and it seems it was already mentioned here. However the thread seemed to have died. This is worrisome because it's rather a severe security vulnerability. OpenSSH seems to have changed behaviour to canonicalize host names _before_ looking up keys in known_hosts. This is BAD. AWFUL. TERRIBLE. This

Interestingly enough I had this same problem today.... 1. I created the directory and permissions for the directory " /var/lib/asterisk/festivalcache/ " (per the comment in the festival.conf file) 2. I had to comment out some things in the festival.conf file: the "host" line, the "port" line, and the "festivalcommand" line. I have also noticed the

----- Original Message ----- > From: "Simon Banton" <centos at web.org.uk> > To: "CentOS mailing list" <centos at centos.org> > Sent: Wednesday, January 28, 2015 6:10:34 AM > Subject: Re: [CentOS] CVE-2015-0235 - glibc gethostbyname > > Hi, > > For reasons which are too tiresome to bore you all with, I have an > obligation to look after

Dear Aishwarya Priyadarshini, Welcome to R-help! Most people here aren't affiliated with R Foundation. ? Wed, 26 Jun 2024 17:03:37 +0000 "Priya, Aishwarya via R-help" <r-help at r-project.org> ?????: > I am reaching out to seek your guidance on addressing the security > vulnerability CVE-2024-27322. > To address this issue effectively, it appears that we need to

Hi, Tavis Ormandy found some bugs in OpenSSL's ASN.1 and buffer code that can be exploited to cause a heap overflow: http://lists.grok.org.uk/pipermail/full-disclosure/2012-April/086585.html Fortunately OpenSSH's sshd is not vulnerable - it has avoided the use of ASN.1 parsing since 2002 when Markus wrote a custom RSA verification function (openssh_RSA_verify):

All, There seems to be a hullaboo about a vulnerability in R when deserializing untrusted data: https://hiddenlayer.com/research/r-bitrary-code-execution https://nvd.nist.gov/vuln/detail/CVE-2024-27322 https://www.kb.cert.org/vuls/id/238194 Apparently a fix was made for R 4.4.0, but I see no mention of it in the changes report: https://cloud.r-project.org/bin/windows/base/NEWS.R-4.4.0.html

https://bugzilla.redhat.com/show_bug.cgi?id=1251157 This is not a vulnerability in libguestfs, but because we always give a virtio-serial port to each guest (since that is how guest-host communication happens), an escalation from the appliance to the host qemu process is possible. This could affect you if: - your libguestfs program runs untrusted programs out of the guest (eg. using

Synopsis Applications can mmap sound driver DMA memory into their address space (see http://www.4front-tech.com for API documentation). When the application closes the audio fd, it still has the mapping to the DMA buffer. It can now interfere with other apps playing/recording audio. (i.e. the driver should prevent opening the sound driver again while another app holds mappings open to it) But

Hi Ivan and R - Help Team, Thank you for your prompt response and the helpful information. I have another query: Is there a way to patch or upgrade the existing installation to version 4.4.0, rather than having to uninstall the older version and then install the latest one? A direct upgrade or patch would greatly simplify the process and reduce downtime. Your guidance on this matter would be

Dear NUT users, I recently came across a MAJOR potential flaw in the network server (upsd), that results, when exploited, in a crash of this server [1] This is the first security flaw in this software, since it's very beginning (~15 years)! It is still potential, and not actual, since Sebastian's report is a first-timer. But it should be very seriously considered, and you should take all

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-04:06.ipv6 Security Advisory The FreeBSD Project Topic: setsockopt(2) IPv6 sockets input validation error Category: core Module: kernel

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-04:06.ipv6 Security Advisory The FreeBSD Project Topic: setsockopt(2) IPv6 sockets input validation error Category: core Module: kernel

Processing commands for control at bugs.debian.org: > ## dear clint. > ## > ## release goals are release goals and not release blockers. > ## please learn the difference and discuss this beforehand. > ## > ## thanks. > ## > > severity 382189 serious > ## > Bug #382189 [nbd-server] no IPv6 support > ## > Severity set to 'serious' from

Hey. I'm also a bit concerned about this issue... On Tue, 2019-01-22 at 13:48 +1100, Damien Miller wrote: > Don't use > scp with untrusted servers. But that would effectively mean one has to toss scp. Reality is simply that most peers cannot be really trusted? just imagine all the administration work which is done from some user/admin's computer to countless servers (running

Packages are being built for CentOS 5, 6 & 7 at the moment: https://twitter.com/CentOS/status/560128242682966017 & https://twitter.com/CentOS/status/560138182441070592 On 27 January 2015 at 20:22, Valeri Galtsev <galtsev at kicp.uchicago.edu> wrote: > > On Tue, January 27, 2015 1:58 pm, Peter Lawler wrote: > > On 28/01/15 04:47, Always Learning wrote: > >> >

> I see. For IP4 addresses, will ups@192.168.0.1:3493 still work as expected? -- Peter Yes. Whatever is between '@' and the optional ':<portnumber>' is passed as hostname. Brackets (in case of domain literals) are removed. One thing to note, in the released versions the use of IPv4 addresses for a hostname (in upsclient.c) is not guaranteed to work (according to POSIX):