Re: Vulnerability
On 9/30/2013 10:05, Jerry wrote: Has this been rectified: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-5710 Yes. http://www.freebsd.org/security/advisories/FreeBSD-SA-13:13.nullfs.asc http://svnweb.freebsd.org/base?view=revisionrevision=255442 -- staticsafe O ascii ribbon campaign - stop html mail - www.asciiribbon.org Please don't top post. It is not logical. Please don't CC me! I'm subscribed to whatever list I just posted on. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Vulnerability
Jerry je...@seibercom.net writes: Has this been rectified: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-5710 If you read the page at that link, you will find the answer. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Vulnerability
This was announced on security-advisor...@freebsd.org on September 10th, 2013. The relevant commits, as taken from the announcement, are: Branch/path Revision - - stable/8/ r255445 releng/8.3/ r255446 releng/8.4/ r255447 stable/9/ r255443 releng/9.1/ r255448 releng/9.2/ r255444 - - On Tue, Oct 1, 2013 at 12:05 AM, Jerry je...@seibercom.net wrote: Has this been rectified: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-5710 -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Vulnerability Database,Compile ports under Security Warnings.
On Sun, May 23, 2010 at 10:29:45PM +0100, Luca Renaud wrote: Krb5-1.8.1 is object of a security warning,and I am not able to compile it.It tells me to update the ports tree and try again,which I have done several times but the same warning stands. Is this port not yet security updated with a security patch? It sounds like it. Is there a way to compile without the security updated/patched tree? # make DISABLE_VULNERABILITIES=yes install clean Before doing that, make sure that the vulnerability portaudit reports isn't going to leave you open to compromise. Portaudit should give you a URL to visit to check. Regards, -- Frank Contact info: http://www.shute.org.uk/misc/contact.html ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Vulnerability check disabled
On Wed, Feb 04, 2004 at 07:31:27PM +1100, Gautam Gopalakrishnan wrote: Hello, Hope I'm not missing something obvious, but since today morning, I've been getting wierd warnings when running make in the ports: Ports questions should be asked on ports@ Kris pgp0.pgp Description: PGP signature
Re: Vulnerability check disabled
On Wed, 4 Feb 2004 19:31:27 +1100 Gautam Gopalakrishnan [EMAIL PROTECTED] wrote: Hello, Hope I'm not missing something obvious, but since today morning, I've been getting wierd warnings when running make in the ports: [madras!/usr/ports/www/apache13]# make fetch-recursive === Fetching all distfiles for apache-1.3.29_1 and dependencies === Vulnerability check disabled === Vulnerability check disabled === Vulnerability check disabled === Vulnerability check disabled [madras!/usr/ports/www/apache13]# cd ../mod_php4 [madras!/usr/ports/www/mod_php4]# make fetch === Vulnerability check disabled [madras!/usr/ports/www/mod_php4]# Happened in www/zope as well. What about reading /usr/ports/CHANGES ? and From: Joe Marcus Clarke [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: HEADS UP: MAJOR changes to the ports system thread on ports ? -- IOnut Unregistered ;) FreeBSD user ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Vulnerability check disabled
On Wed, 2004-02-04 at 13:17, Ion-Mihai Tetcu wrote: On Wed, 4 Feb 2004 19:31:27 +1100 Gautam Gopalakrishnan [EMAIL PROTECTED] wrote: Hello, Hope I'm not missing something obvious, but since today morning, I've been getting wierd warnings when running make in the ports: [madras!/usr/ports/www/apache13]# make fetch-recursive === Fetching all distfiles for apache-1.3.29_1 and dependencies === Vulnerability check disabled === Vulnerability check disabled === Vulnerability check disabled === Vulnerability check disabled [madras!/usr/ports/www/apache13]# cd ../mod_php4 [madras!/usr/ports/www/mod_php4]# make fetch === Vulnerability check disabled [madras!/usr/ports/www/mod_php4]# Happened in www/zope as well. What about reading /usr/ports/CHANGES ? Yep, that will talk about it. and From: Joe Marcus Clarke [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: HEADS UP: MAJOR changes to the ports system thread on ports ? This thread doesn't cover the vulnerability change. Basically, we now have the ability to keep a dynamic database of ports vulnerabilities which the ports system can check. If you do not have the database installed, you'll get the benign Vulnerability check disabled message. Joe -- PGP Key : http://www.marcuscom.com/pgp.asc signature.asc Description: This is a digitally signed message part
Re: Vulnerability check disabled
On Wed, Feb 04, 2004 at 01:25:44PM -0500, Joe Marcus Clarke wrote: On Wed, 2004-02-04 at 13:17, Ion-Mihai Tetcu wrote: On Wed, 4 Feb 2004 19:31:27 +1100 Gautam Gopalakrishnan [EMAIL PROTECTED] wrote: Hello, Hope I'm not missing something obvious, but since today morning, I've been getting wierd warnings when running make in the ports: [madras!/usr/ports/www/apache13]# make fetch-recursive === Fetching all distfiles for apache-1.3.29_1 and dependencies === Vulnerability check disabled === Vulnerability check disabled === Vulnerability check disabled === Vulnerability check disabled [madras!/usr/ports/www/apache13]# cd ../mod_php4 [madras!/usr/ports/www/mod_php4]# make fetch === Vulnerability check disabled [madras!/usr/ports/www/mod_php4]# Happened in www/zope as well. What about reading /usr/ports/CHANGES ? Yep, that will talk about it. and From: Joe Marcus Clarke [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: HEADS UP: MAJOR changes to the ports system thread on ports ? This thread doesn't cover the vulnerability change. Basically, we now have the ability to keep a dynamic database of ports vulnerabilities which the ports system can check. If you do not have the database installed, you'll get the benign Vulnerability check disabled message. True, but would it be possible to just have the warning emitted once, say just before the build target? Ceri -- pgp0.pgp Description: PGP signature
Re: Vulnerability check disabled
On Wed, 04 Feb 2004 13:25:44 -0500 Joe Marcus Clarke [EMAIL PROTECTED] wrote: On Wed, 2004-02-04 at 13:17, Ion-Mihai Tetcu wrote: On Wed, 4 Feb 2004 19:31:27 +1100 Gautam Gopalakrishnan [EMAIL PROTECTED] wrote: Hello, Hope I'm not missing something obvious, but since today morning, I've been getting wierd warnings when running make in the ports: [madras!/usr/ports/www/apache13]# make fetch-recursive === Fetching all distfiles for apache-1.3.29_1 and dependencies === Vulnerability check disabled === Vulnerability check disabled === Vulnerability check disabled === Vulnerability check disabled [madras!/usr/ports/www/apache13]# cd ../mod_php4 [madras!/usr/ports/www/mod_php4]# make fetch === Vulnerability check disabled [madras!/usr/ports/www/mod_php4]# Happened in www/zope as well. What about reading /usr/ports/CHANGES ? Yep, that will talk about it. I hope did get a sleep since freezing the ports ;) ? From: Joe Marcus Clarke [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: HEADS UP: MAJOR changes to the ports system thread on ports ? This thread doesn't cover the vulnerability change. Basically, we now have the ability to keep a dynamic database of ports vulnerabilities which the ports system can check. If you do not have the database installed, you'll get the benign Vulnerability check disabled message. Type: FEATURE Title: Do not install ports with security vulnerabilities Affects: bsd.port.mk Description: A new vulnerabilities database has been added to the ports system in order to keep more accurate, up-to-date, track of security vulnerabilities. The ports system now knows how to query that database and dynamically prevents the installation of vulnerable ports. PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=62039 Submitted by: eik Now, maybe this could be clarified a little bit in CHANGES ? Like: __ For using the new security feature of ports infrastructure, you should: cd /usr/ports/security/portaudit; make install /usr/local/etc/periodic/daily/330.fetchaudit To test: cd /usr/ports/security/vulnerability-test-port make INSTALLATION_DATE=`date -u -v-14d +%Y.%m.%d` install A message like this should appear: === vulnerability-test-port-2004.01.14 has known vulnerabilities: Not vulnerable, just a test port (database: 2004-01-28). Reference: http://www.freebsd.org/cgi/cvsweb.cgi/ports/security/vulnerability-test-port/ Please update your ports tree and try again. *** Error code 1 If you don't install this port, for the majority of make's targtets you will get the following message: === Vulnerability check disabled __ IMHO, as this is a log desired feature, a news on annouce@ / security / security-notifications could be send. Now, what is the status of the vulnerabilities database ? -- IOnut Unregistered ;) FreeBSD user ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Vulnerability check disabled
On Wed, 4 Feb 2004 21:26:01 +0200 Ion-Mihai Tetcu [EMAIL PROTECTED] wrote: [..] Type: FEATURE Title: Do not install ports with security vulnerabilities [..] Now, maybe this could be clarified a little bit in CHANGES ? Like: __ For using the new security feature of ports infrastructure, you should: cd /usr/ports/security/portaudit; make install Note that this is a prerelease version, it is mostly usable for committers that want to contribute to the project, and can currently not be relied upon as an extensive security auditing tool. /usr/local/etc/periodic/daily/330.fetchaudit To test: cd /usr/ports/security/vulnerability-test-port make INSTALLATION_DATE=`date -u -v-14d +%Y.%m.%d` install A message like this should appear: === vulnerability-test-port-2004.01.14 has known vulnerabilities: Not vulnerable, just a test port (database: 2004-01-28). Reference: http://www.freebsd.org/cgi/cvsweb.cgi/ports/security/vulnerability-test-port/ Please update your ports tree and try again. *** Error code 1 If you don't install this port, for the majority of make's targtets you will get the following message: === Vulnerability check disabled __ IMHO, as this is a log desired feature, a news on annouce@ / security / security-notifications could be send. Now, what is the status of the vulnerabilities database ? Did I just responded to my question ? -- IOnut Unregistered ;) FreeBSD user ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Vulnerability check disabled
On Wed, 4 Feb 2004 19:12:57 + Ceri Davies [EMAIL PROTECTED] wrote: On Wed, Feb 04, 2004 at 01:25:44PM -0500, Joe Marcus Clarke wrote: On Wed, 2004-02-04 at 13:17, Ion-Mihai Tetcu wrote: On Wed, 4 Feb 2004 19:31:27 +1100 Gautam Gopalakrishnan [EMAIL PROTECTED] wrote: Hello, Hope I'm not missing something obvious, but since today morning, I've been getting wierd warnings when running make in the ports: [madras!/usr/ports/www/apache13]# make fetch-recursive === Fetching all distfiles for apache-1.3.29_1 and dependencies === Vulnerability check disabled [..] This thread doesn't cover the vulnerability change. Basically, we now have the ability to keep a dynamic database of ports vulnerabilities which the ports system can check. If you do not have the database installed, you'll get the benign Vulnerability check disabled message. True, but would it be possible to just have the warning emitted once, say just before the build target? Yes, please don't break fetching with this. Fetch should mean fetch. Stop building if necessary, but let fetch go. -- IOnut Unregistered ;) FreeBSD user ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vulnerability in su?
On Sat, Nov 08, 2003 at 08:23:25PM -0500, kirt wrote: is this a known issue? i didn't search to hard for a fix or anything since i quickly fixed it myself, but i thought that a situation like that could make for some interesting (read *bad*) situations. It's certainly possible to compromise your system in this way if you incorrectly update your /etc (e.g. by making a mistake with mergemaster). Kris pgp0.pgp Description: PGP signature
Re: vulnerability in su?
On Sat, Nov 08, 2003 at 10:49:35PM -0800, Derrick Ryalls wrote: while recently cvsup'ing my box here at home, i had a weird thing happen... i had already built world, built and installed the kernel, installed world (including all appropriate reboots), and when i brought it back up, but prior to running mergemaster, i popped the jumper on the circuit the box is on. my ups is somewhat wimpy, and only lasts a couple minutes (the fuse trips all the time too.. stupid apartment wiring can't handle 2 computers and the washer and dryer at once =P ) so i made it a priority to go ahead and shut the box down. after fixing said jumper and bring the box back up i noticed that i could now su like a madman, without ever being prompted for passwords. i then remembered that i hadn't run mergemaster yet, so i ran it again and rebooted for safe measure and su started asking for passwords again. I think the only time this happens is if the root password is blank. It is possible that one of your mergemaster runs put in the default root password (blank). well, it wasn't just the root password... for example i was able to login to one of my non-wheel accounts, su to my personal account (which is in wheel), and then su right to root as well. in addition, none of the passwords were actually blank, because i actually plugged a monitor and keyboard into the box and logged in locally as root, which required me to put my password in. all of my accounts did, in fact. -kirt ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: vulnerability in su?
while recently cvsup'ing my box here at home, i had a weird thing happen... i had already built world, built and installed the kernel, installed world (including all appropriate reboots), and when i brought it back up, but prior to running mergemaster, i popped the jumper on the circuit the box is on. my ups is somewhat wimpy, and only lasts a couple minutes (the fuse trips all the time too.. stupid apartment wiring can't handle 2 computers and the washer and dryer at once =P ) so i made it a priority to go ahead and shut the box down. after fixing said jumper and bring the box back up i noticed that i could now su like a madman, without ever being prompted for passwords. i then remembered that i hadn't run mergemaster yet, so i ran it again and rebooted for safe measure and su started asking for passwords again. I think the only time this happens is if the root password is blank. It is possible that one of your mergemaster runs put in the default root password (blank). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Vulnerability in PHP Clarification?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://www.php.net Has a security warning posted on their site. It affects 4.2.0 and 4.2.1. An update to 4.2.2 is highly recommended. chris wrote: | Can anyone clarify this a bit? I see that they state that 4.2.0 and 4.2.1 | are vulnerable. | If you goto the link provided | http://security.e-matters.de/advisories/012002.html | It states that the older versions are vulnerable and that the 4.2 tree is | not affected. | Not to mention that link is dated 5months old! | What is right? | | -Chris | | | - Original Message - | From: CERT Advisory [EMAIL PROTECTED] | To: [EMAIL PROTECTED] | Sent: Monday, July 22, 2002 4:09 PM | Subject: CERT Advisory CA-2002-21 Vulnerability in PHP | | | | |-BEGIN PGP SIGNED MESSAGE- | |CERT Advisory CA-2002-21 Vulnerability in PHP | | Original release date: July 22, 2002 | Last revised: -- | Source: CERT/CC | | A complete revision history can be found at the end of this file. | |Systems Affected | | * Systems running PHP versions 4.2.0 or 4.2.1 | |Overview | | A vulnerability has been discovered in PHP. This vulnerability could | be used by a remote attacker to execute arbitrary code or crash PHP | and/or the web server. | |I. Description | | PHP is a popular scripting language in widespread use. For more | information about PHP, see | | http://www.php.net/manual/en/faq.general.php | | The vulnerability occurs in the portion of PHP code responsible for | handling file uploads, specifically multipart/form-data. By sending a | specially crafted POST request to the web server, an attacker can | corrupt the internal data structures used by PHP. Specifically, an | intruder can cause an improperly initialized memory structure to be | freed. In most cases, an intruder can use this flaw to crash PHP or | the web server. Under some circumstances, an intruder may be able to | take advantage of this flaw to execute arbitrary code with the | privileges of the web server. | | You may be aware that freeing memory at inappropriate times in some | implementations of malloc and free does not usually result in the | execution of arbitrary code. However, because PHP utilizes its own | memory management system, the implementation of malloc and free is | irrelevant to this problem. | | Stefan Esser of e-matters GmbH has indicated that intruders cannot | execute code on x86 systems. However, we encourage system | administrators to apply patches on x86 systems as well to guard | against denial-of-service attacks and as-yet-unknown attack techniques | that may permit the execution of code on x86 architectures. | | This vulnerability was discovered by e-matters GmbH and is described | in detail in their advisory. The PHP Group has also issued an | advisory. A list of vendors contacted by the CERT/CC and their status | regarding this vulnerability is available in VU#929115. | | Although this vulnerability only affects PHP 4.2.0 and 4.2.1, | e-matters GmbH has previously identified vulnerabilities in older | versions of PHP. If you are running older versions of PHP, we | encourage you to review | http://security.e-matters.de/advisories/012002.html | |II. Impact | | A remote attacker can execute arbitrary code on a vulnerable system. | An attacker may not be able to execute code on x86 architectures due | to the way the stack is structured. However, an attacker can leverage | this vulnerability to crash PHP and/or the web server running on an | x86 architecture. | |III. Solution | |Apply a patch from your vendor | | Appendix A contains information provided by vendors for this advisory. | As vendors report new information to the CERT/CC, we will update this | section and note the changes in our revision history. If a particular | vendor is not listed below, we have not received their comments. | Please contact your vendor directly. | |Upgrade to the latest version of PHP | | If a patch is not available from your vendor, upgrade to version | 4.2.2. | |Deny POST requests | | Until patches or an update can be applied, you may wish to deny POST | requests. The following workaround is taken from the PHP Security | Advisory: | | If the PHP applications on an affected web server do not rely on | HTTP POST input from user agents, it is often possible to deny POST | requests on the web server. | | In the Apache web server, for example, this is possible with the | following code included in the main configuration file or a | top-level .htaccess file: | | Limit POST |Order deny,allow |Deny from all | /Limit | | Note that an existing configuration and/or .htaccess file may have | parameters contradicting the example given
