Re: PEAR packages potentially contain malicious code

[Remko Lodder]

Hi Stefan,

> On 21 Jan 2019, at 21:18, Stefan Bethke  wrote:
> 
> I’ve just learned that the repository for the PHP PEAR set of extensions had 
> their distribution server compromised.
> 
> https://twitter.com/pear/status/1086634503731404800
> 
> I don’t really work with PHP much apart from installing packages of popular 
> PHP web apps on my servers, so I can’t tell whether this code made it onto 
> machines building from PEAR sources, or even into FreeBSD binary packages of 
> PEAR extensions. Given the large user base for these packages, some advice to 
> FreeBSD users might be well received.

Thank you for sending the headsup to the FreeBSD users.
I have CC’ed ports-secteam, they will handle with due care when more 
information is available and they can act upon something.
I have BCC’ed the maintainer for the PHP port(s), but I am not entirely sure 
whether he maintains all the pear ports as well.

Again, thank you.

Best regards,
Remko
Hat: Security Team

> 
> 
> Thanks,
> Stefan
> 
> --
> Stefan BethkeFon +49 151 14070811
> 
> ___
> freebsd-security@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"



signature.asc
Description: Message signed with OpenPGP

Re: SQLite vulnerability

[Remko Lodder]

Hi,

It’s sad to see that you are still as negative as you where not that long ago.

I said before that If you rely on the information being up to date, you should
sponsor the FF or pay someone to do the work for you. You keep forgetting
that we (security-officer@ and ports-secteam@) are volunteers and that
we do this in our free spare time. You cannot demand that we do things that
you expect us to do without knowing how people lives are going at that same
moment. If they have to choose between your whining and their kids or
family, I would also choose the family.

I do not think the others need to step in for this one, your constant negative
attitude towards our ports-secteam people is getting annoying and a waste
of our precious time. So either start sending patches, contribute, or understand
that this is voluntarily and that their priorities might not be your priority.

Thank you, once and for all,
Remko.

> On 16 Dec 2018, at 17:13, Roger Marquis  wrote:
> 
> Thanks to Chrome{,ium} a recently discovered SQLite exploit has been all
> over the news for a week now.  It is patched on all Linux platforms but
> has not yet shown up in FreeBSD's vulxml database.  Does this mean:
> 
> A) FreeBSD versions prior to 3.26.0 are not vulnerable, or
> 
> B) the ports-secteam is not able to properly maintain the vulnerability
> database?
> 
> If the latter perhaps someone from the security team could let us know
> how such a significant vulnerability could go unflagged for so long and,
> more importantly, what might be done to address the gap in reporting?
> 
> Roger Marquis



signature.asc
Description: Message signed with OpenPGP

Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-18:02.ntp

[Remko Lodder]

> On 7 Mar 2018, at 12:50, David Chisnall  wrote:
> 
> Were these changes and the kernel changes tested together on Xen?  After 
> updating to -p7, I get about 10 seconds of uptime on a Xen VM before the 
> kernel panics with a double fault and reboots.  Disabling ntpd results in a 
> stable system.  On an AMD system without a hypervisor, I don’t see any 
> instability.
> 
> David
> 
>> 

Hi David,

We have no Xen setup as far as I know so in short; these changes were not 
tested on Xen as far as I know.

Cheers
Remko



signature.asc
Description: Message signed with OpenPGP

Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-18:02.ntp

[Remko Lodder]

> On 7 Mar 2018, at 12:50, David Chisnall  wrote:
> 
> Were these changes and the kernel changes tested together on Xen?  After 
> updating to -p7, I get about 10 seconds of uptime on a Xen VM before the 
> kernel panics with a double fault and reboots.  Disabling ntpd results in a 
> stable system.  On an AMD system without a hypervisor, I don’t see any 
> instability.
> 
> David
> 
>> 

Hi David,

We have no Xen setup as far as I know so in short; these changes were not 
tested on Xen as far as I know.

Cheers
Remko



signature.asc
Description: Message signed with OpenPGP

Re: BlueBorne

[Remko Lodder]

> On 18 Sep 2017, at 15:06, Ian Smith <smi...@nimnet.asn.au> wrote:
> 
> Hi,
> 
> I suppose Those Who Need To Know would be onto this, but apart from this
> newspaper article the other day, I've come across no other mention.
> 
> "Bluetooth flaw allows airborne viruses silently to attack
> internet-enabled devices"
> 
> <http://www.smh.com.au/technology/consumer-security/bluetooth-flaw-allows-airborne-viruses-silently-to-attack-internetenabled-devices-20170914-gyh5o0.html>
> 
> I know very little about Bluetooth, only recently starting to use it
> myself between a couple of phones, but the linked-to PDF paper I found
> interesting and informative, if not perhaps being overly alarmist?
> 
> <http://go.armis.com/hubfs/BlueBorne%20Technical%20White%20Paper.pdf>
> 
> Does this / might this / could this impact on FreeBSD's bt stack?  I
> flipped through https://lists.freebsd.org/pipermail/freebsd-bluetooth/
> 's last year pretty quickly, there's not a lot there.  After reading the
> paper I wouldn't dare try diving into this stack, I'd never get back ..
> 
> cheers, Ian


We believe that we are not affected at this stage.

Thanks,
Remko Lodder
on behalf of The FreeBSD Security Team



signature.asc
Description: Message signed with OpenPGP

Re: pkg audit false negatives

[Remko Lodder]

> On 14 Aug 2017, at 05:32, Roger Marquis  wrote:
> 
>> I do not think that holds:
>> 
>> 
>> 17521php -- multiple vulnerabilities
>> 17522
>> 17523  
>> 17524php55
>> 175255.5.38
>> 17526  
>> 
>> This is an entry from svnweb, for php55, which was added in 2016(07-26).
>> 
>> So this entry is there. Thus it did not disappear from VuXML at least.
> 
> You are right Remko.  It looks like there was a policy or at least a
> practice change about a year ago.  Even have an archived email from
> Gerhard Schmidt who first noticed it back in Aug 2016.  My fault for not
> doing sufficient fact rechecking,
> 
> So we are safe from false negatives after all.  Hurray, I can stop
> relying on pkg-version (for this).
> 
> That leaves just unpackaged base as FreeBSD's remaining audit weakness.

Hi, I am happy that I can reduce your worry factor a bit ;-)

Can you share what the audit weakness is? freebsd-update cron checks
whether or not an update is available and then emails you. If you run
-RELEASE, then that means that either an EN or SA had been released..

Cheers
Remko


> 
> Roger
> 
> 
> ___
> freebsd-security@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"



signature.asc
Description: Message signed with OpenPGP

Re: pkg audit false negatives

[Remko Lodder]

> On 12 Aug 2017, at 02:37, Roger Marquis <marq...@roble.com> wrote:
> 
> On Fri, 11 Aug 2017, Remko Lodder wrote:
> 
>> If an entry is removed from the ports/pkg tree?s and it is also removed
>> from VuXML, then yes, it will no longer get marked in your local
>> installation. That?s a bit of a chicken and egg basically. Although I do
>> not recall that it ever happened that ports that are no longer there, are
>> removed from VuXML as well. (And I follow that since 2004).
>> Do you have a more concrete example that we can dive into to see what is
>> going on/going wrong?
> 
> Should be able to find missing vulxml entries for most anything that has
> been deprecated from the ports tree but most of the ones I've seen are
> for web programming languages, particularly php.

I do not think that holds:


17521   php -- multiple vulnerabilities
17522   
17523 
17524   php55
17525   5.5.38
17526 

This is an entry from svnweb, for php55, which was added in 2016(07-26).

So this entry is there. Thus it did not disappear from VuXML at least.

Can you show such a packet from your local installation(s) and present a
``pkg audit -F`` along side it. I would also like to see a detailed pkg info
from the affected pkg.

Thanks a lot in advance,
Remko

> 
> For example when php5X was dropped it also disappeared from vulxml, with
> no small number of servers still using it.  If those sites depended on
> pkg-audit to tell them they had a vulnerability, well, they were out of
> luck.  There was no warning, no error, no disclaimer, pkg-audit did and
> still does nothing different than it would for a non-vulnerable port or
> package.
> 
> There may be more vulnerabilities in the wild from non-packaged base as
> it is larger but at least people are working on that.  Pkg-audit
> tracking of installed but deprecated ports OTOH, seems to have fallen
> through the cracks.  Even the FreeBSD Foundation and the ports-security
> teams appear to be ignoring this issue.
> 
> Roger Marquis



signature.asc
Description: Message signed with OpenPGP

Re: pkg audit false negatives

[Remko Lodder]

> On 11 Aug 2017, at 23:47, Roger Marquis  wrote:
> 
>> It had been resolved for dovecot (it will now match both variants, since 
>> people might still have
>> the old variant of the port installed) and there is a new paragraph added to 
>> the porters handbook
>> which tells that we need to have a look at the vuxml entries.
> 
> Thanks Remko.

No problemo :)

> 
>> Hope this solves your issue,
> 
> It may for renamed ports/pkgs but doesn't appear to for deprecations.
> Once ports are dropped they do not show up in pkg-audit despite having
> been installed via pkg and/or ports.  That's the false negative that
> appears to still be a problem.

Ports / pkgs that get renamed are now changed and/or added in VuXML as well.
So the old variant and the new variant of the name’s would both be listed in 
pkg audit.

pkg audit parses VuXML, it also does a check on what is locally registered in 
it’s database.

For example if you have a/b installed. And that has a marking in VuXML : 
b
then it would hit on the package you have. If a/b gets removed for some reason, 
and it is still in VuXML
and you have it locally registered. Then it would be still be matched (or 
should).

If an entry is removed from the ports/pkg tree’s and it is also removed from 
VuXML, then yes, it will
no longer get marked in your local installation. That’s a bit of a chicken and 
egg basically. Although
I do not recall that it ever happened that ports that are no longer there, are 
removed from VuXML as
well. (And I follow that since 2004).

Do you have a more concrete example that we can dive into to see what is going 
on/going wrong?

Cheers
Remko


> 
> Roger



signature.asc
Description: Message signed with OpenPGP

Re: pkg audit false negatives

[Remko Lodder]

Hi Roger,

> On 11 Aug 2017, at 17:14, Remko Lodder <re...@freebsd.org> wrote:
> 
> Hi Roger,
> 
>> On 11 Aug 2017, at 04:41, Roger Marquis <marq...@roble.com> wrote:
>> 
>> In the past pkg-audit and even pkg-version have not been reliable tools
>> where installed ports or packages have been subsequently discontinued or
>> renamed.  Today, however, I notice that dovecot2 is still showing up in
>> the output of pkg-version despite the port having been renamed to
>> dovecot (without the numeric suffix) several days ago.
> 

It had been resolved for dovecot (it will now match both variants, since people 
might still have
the old variant of the port installed) and there is a new paragraph added to 
the porters handbook
which tells that we need to have a look at the vuxml entries.

Hope this solves your issue,
Remko



signature.asc
Description: Message signed with OpenPGP

Re: pkg audit false negatives

[Remko Lodder]

Hi Roger,

> On 11 Aug 2017, at 04:41, Roger Marquis  wrote:
> 
> In the past pkg-audit and even pkg-version have not been reliable tools
> where installed ports or packages have been subsequently discontinued or
> renamed.  Today, however, I notice that dovecot2 is still showing up in
> the output of pkg-version despite the port having been renamed to
> dovecot (without the numeric suffix) several days ago.

Yes, there is a difference between renaming a port, and renaming the vuxml 
(which is the
database behind pkg audit etc.) entries. The entries are listed as ‘dovecot2-*’ 
there and
when renaming a port these entries should ideally be renamed too.

It seems that that was not under consideration at the name change moment(s).

I’ll try to look into this (starting by prodding the person(s) who did the 
rename) and asking them
to rename the entries in vuxml as well.

> 
> Does this mean there has been a policy change?  If so does it cover
> pkg-audit as well?

There had been no policy change. The application backend is just matching on 
what
was recorded at the moment it was added.

Thanks for the notification though, we should add that to the porters-handbook.

Cheers
REmko

> 
> Roger
> ___
> freebsd-security@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"



signature.asc
Description: Message signed with OpenPGP

Re: The Stack Clash vulnerability

[Remko Lodder]

> On 23 Jun 2017, at 01:19, Michelle Sullivan  wrote:
> 
> Peter,
> 
> Peter Jeremy wrote:
>> 
>> paying someone to provide whatever level of support you want.  With
>> respect to your 9.x servers, no-one is saying you must replace the
>> hardware, just that the FreeBSD Project will not continue to provide
>> you with free support whilst you choose to run 9.x on them.  Note that
>> 
> You mistake me for someone who needs or is asking for support.
> 
> I already have the proposed patch available to me on my servers, I'm not 
> convinced it solves the issue, merely making it a *lot* more difficult to 
> exploit, however that was my 'first look' I have a lot more to understand and 
> think about and there are many more people of higher intelligence looking at 
> it than me.
> 
> That said, I'm suggesting that given the amount of time this issue has been 
> around and that it was supposedly fixed many years ago, that one should 
> consider a special case backport for those that are not capable of creating 
> their own patches... and before throwing accusations around you should 
> consider how many times I have ever suggested that a particular bug gets 
> backported...  If you can't be bothered to check, this is the first since I 
> started using FreeBSD in 2003.

Okay, lets cool this thread down. There are no accusations in this thread, and 
they are not needed nor welcome either.

I am going to make a general note below, this is not something that is aimed at 
_you_ personally.

My general note is about the policy we maintain to update supported systems. 
Once we are ready with the currently supported branches, it might be “simple” 
for “someone” (not the FreeBSD Security Team) to back port those changes into 
older -STABLE branches. I am stating that we not perse will do that. But if 
someone has time and effort to support such a change, it will be done. People 
like hps@ merge periodically to older branches that are officially no longer 
supported. That does not mean that they cannot do that, but that they have an 
interest in doing so, which is perfectly fine (ofcourse).

So; if the patch is applicable for older branches as well (stable I mean), 
someone needs to find a committer that can vouch for it and also import it into 
the stable branches. He or She has to understand that it might cause problems 
and they need to be investigated by that person in that case.

If someone, who is commercially using our Operating System, has an urgent need 
to have this in a -STABLE branch, I am sure that a few bucks here and there can 
make it worth someone’s (free) time to support that.

That’s the way it works, we volunteer for this project, and we do understand 
that people are using our product and even in a commercial sense where people 
make a -lot- of money with “our” work. That is perfectly fine. But we have to 
draw a line in what we can and will support. We also have families, hobby’s, 
other work that obviously also costs time and generate our income(s). Even with 
that we are happy to work on the project, and thus the “product” that we ship. 
But there is a line. There is no more hours in a day then 24. We have to devide 
that in all those regions we are active in. That is where the support policy 
comes in, we accept the fact that we maintain and support releases and stable 
branches after we created them. We do that for a limited amount of time, so 
that we can have a good division between new products, and our other 
activities. So if someone wants to keep a committer/programmer active while he 
could have been playing with his kids, it should be worth his/her while (in 
addition to the work he/she already does for the project) and it’s for the 
committer to decide whether that is indeed worth the while. Perhaps a committer 
is already being payed by someone to do this and he or she will just do it “for 
free”, then everyone benefits and we have to thank the sponsor for that.

So given the above, and now I am responding to your request, I do not think we 
should break our tradition. There are many things that are not fixed in older 
branches, OpenSSL comes to mind, we simply have to make a choice in what we can 
and cannot do, and be open about that. Branches that are no longer supported, 
will not get official fixes anymore. A committer is free to do so, with the 
note that it -might- cost a few bucks to get that going.

I hope the above is making it a bit more clear on why we have to draw a line 
somewhere, and what it might take to get it in the STABLE branches. It can be 
done, but you need to find someone who can do that, with potential consequences.

Thanks,
Remko

> 
> --
> Michelle Sullivan
> http://www.mhix.org/
> 
> ___
> freebsd-security@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"



signature.asc

Re: The Stack Clash vulnerability

[Remko Lodder]

> On 22 Jun 2017, at 03:10, Michelle Sullivan  wrote:
> 
> Ed Maste wrote:
>> On 20 June 2017 at 16:22, Ed Maste  wrote:
>>> On 20 June 2017 at 04:13, Vladimir Terziev  wrote:
 Hi,
 
 I assume FreeBSD security team is already aware about the Stack Clash 
 vulnerability, that is stated to affect FreeBSD amongst other Unix-like OS.
>>> Yes, the security team is aware of this. Improvements in stack
>>> handling are in progress (currently in review).
>> I would like to provide some additional background on this issue.
>> First I'd like to thank Qualys for their detailed and thorough
>> investigation, which is contributing directly to improving FreeBSD.
>> 
>> The FreeBSD security team is aware of and is monitoring this issue,
>> but is not directly developing in the changes that are in progress.
>> The issue under discussion is a limitation in a vulnerability
>> mitigation technique. Changes to improve the way FreeBSD manages stack
>> growth, and mitigate the issue demonstrated by Qualys'
>> proof-of-concept code, are in progress by FreeBSD developers
>> knowledgeable in the VM subsystem. These changes are expected to be
>> committed to FreeBSD soon, and from there they will be merged to
>> stable branches and into updates for supported releases.
> 
> One would hope considering the nature and potential threat this would be one 
> of those fixes back ported to previous -STABLE trees as well.
> 

Hi Michelle,

On a general note:

When we fix issues, they go to the supported branches / releases. 7.x for 
example is no longer supported and is not likely to receive this care and 
attention unless someone is willing to support such a change to that branch. 
For supported branches, such a change is likely to be merged to those branches 
and also to supported releases depending on the determination. E.g. A Security 
Advisory (SA) or Errata Notice (EN) will be merged to affected -RELEASES as 
well. If an issue does not get one of those two markers, the issue will not be 
merged to -RELEASES but can be merged to -STABLE branches.

The above is a general note and not specifically pointed towards “The Stack 
Clash” documents, so this can support potential future questions in the same 
area as well :-)

Cheers
Remko

> 
> --
> Michelle Sullivan
> http://www.mhix.org/ 
> 
> ___
> freebsd-security@freebsd.org  mailing 
> list
> https://lists.freebsd.org/mailman/listinfo/freebsd-security 
> 
> To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org 
> "



signature.asc
Description: Message signed with OpenPGP

Re: FreeBSD Security Advisory FreeBSD-SA-17:02.openssl

[Remko Lodder]

> On 23 Feb 2017, at 12:11, Andrea Venturoli  wrote:
> 
> On 02/23/17 08:39, FreeBSD Security Advisories wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>> 
>> =
>> FreeBSD-SA-17:02.opensslSecurity Advisory
>>  The FreeBSD Project
>> 
>> Topic:  OpenSSL multiple vulnerabilities
>> 
>> Category:   contrib
>> Module: openssl
>> Announced:  2017-02-23
>> Affects:All supported versions of FreeBSD.
>> Corrected:  2017-01-26 19:14:14 UTC (stable/11, 11.0-STABLE)
>>2017-02-23 07:11:48 UTC (releng/11.0, 11.0-RELEASE-p8)
>>2017-01-27 07:45:06 UTC (stable/10, 10.3-STABLE)
>>2017-02-23 07:12:18 UTC (releng/10.3, 10.3-RELEASE-p16)
> 
> Is this a typo?
> 
> 10.3-RELEASE-p16 was out on 20170111 (for FreeBSD-SA-17:01).
> 
> Should read p17, shouldn't it?
> 
> bye & Thanks
>   av.

Hi Andrea,

Yes our apologies. We will fix this later today in a new revision.

Thanks and cheers
Remko

> ___
> freebsd-security@freebsd.org  mailing 
> list
> https://lists.freebsd.org/mailman/listinfo/freebsd-security 
> 
> To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org 
> "



signature.asc
Description: Message signed with OpenPGP

Re: Ports Secteam

[Remko Lodder]

Hi,

 
 On June 9, 2015 at 1:59 AM Robert Simmons rsimmo...@gmail.com wrote:
 
 
 On Mon, Jun 8, 2015 at 7:31 PM, Xin Li delp...@delphij.net wrote:
  On 06/08/15 14:37, Robert Simmons wrote:
  I'm sure that the reason these questions have not been answered is
  simply because they may have gotten lost in the volume of traffic
  on freebsd-ports. In the following thread, there are a number of
  folks with enough passion to volunteer time to help with the Ports
  Secteam, but we're having difficulty getting a few basic questions
  answered.
  https://lists.freebsd.org/pipermail/freebsd-ports/2015-May/099268.html
 
  Here are the basic questions:
 
  Who are the members of the Ports Secteam?
 
  Current members include the current security officers (who act as a
  fallback when needed and a contact for liaison for sensitive and
  embargoed information) and:
 
  Eitan Adler (eadler@);
  Jason Helfman (jgh@);
  Martin Wilke (miwi@);
  Eygene Ryabinkin (rea@);
  Sofian Brabez (sbz@);
  Simon L. B. Nielsen (simon@, clusteradm@ liaison);
  Steve Wills (swills@);
  Wesley Shields (wxs@);
  Ryan Steinmetz (zi@);
 
  How does one join the Ports Secteam?
 
  Per previous discussion with portmgr@, members are volunteers selected
  by the Security Officer from active ports committers who have made
  commits in the ports tree in the last 90 days.
 
 Excellent. Thanks for the quick reply!
 
 So, if membership requires committership, what is the next best way to
 help the team?
 ___
 

I think that actively sending patches would help in getting in information
sooner.

A PR with the patch would greatly assist in that.


Cheers

Remko
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: FreeBSD Security Advisory FreeBSD-SA-15:04.igmp (fwd) - ipfw fix?

[Remko Lodder]

 On 25 Feb 2015, at 12:24, Karl Pielorz kpielorz_...@tdx.co.uk wrote:
 
 
 Hi,
 
 Presumably if you don't need IGMP, ipfw can be used to mitigate this on hosts 
 until they're patched / rebooted, i.e.
 
 ipfw add x deny igmp from any to any
 
 ?


This suggests that you can filter the traffic:

Block incoming IGMP packets by protecting your host/networks with a firewall.
 (Quote from the SA).

Br,
Remko

 
 Thanks,
 
 -Karl
 
 -- Forwarded Message --
 Date: 25 February 2015 06:29 +
 From: FreeBSD Security Advisories security-advisor...@freebsd.org
 To: FreeBSD Security Advisories security-advisor...@freebsd.org
 Subject: FreeBSD Security Advisory FreeBSD-SA-15:04.igmp
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
 ===
 == FreeBSD-SA-15:04.igmp   Security
 Advisory   The
 FreeBSD Project
 
 Topic:  Integer overflow in IGMP protocol
 
 ___
 freebsd-security@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-security
 To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

--
/\   Best regards,  | re...@freebsd.org
\ /   Remko Lodder   | remko@EFnet
 Xhttp://www.evilcoder.org/  |
/ \   ASCII Ribbon Campaign  | Against HTML Mail and News



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: FreeBSD Security Advisory FreeBSD-SA-14:31.ntp

[Remko Lodder]

 On 25 Dec 2014, at 18:46, Darren Pilgrim list_free...@bluerosetech.com 
 wrote:
 
 On 12/23/2014 3:33 PM, FreeBSD Security Advisories wrote:
 IV.  Workaround
 
 No workaround is available,
 
 This was fixed in ports/net/ntp on Dec 20, so a workaround exists in the form 
 of disabling the in-base version and installing the port.  In the future, it 
 would be helpful to mention such.

We talk explicitly about the base system, not about ports. We never mentioned 
them and I do not see a reason to start doing so.

That is my personal opinion though, it could be that others think different and 
they are ofcourse entitled to do so.

--
/\   Best regards,  | re...@freebsd.org
\ /   Remko Lodder   | remko@EFnet
 Xhttp://www.evilcoder.org/  |
/ \   ASCII Ribbon Campaign  | Against HTML Mail and News



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: FreeBSD Security Advisory FreeBSD-SA-14:19.tcp

[Remko Lodder]

On 16 Sep 2014, at 18:42, Zoran Kolic zko...@sbb.rs wrote:

 The advisory solution offers 3 options... freebsd-update is the binary 
 approach (option #3) that provides you a new updated generic kernel 
 already compiled.  If you aren't using a generic kernel or want to patch 
 and recompile your own, then you would use the option #2.
 
 Hm! I use custom kernel. Here is what I did using
 freebsd-update:
 I fetched and installed. Then I recompiled the kernel.
 Did I miss the security patch doing this?

If you have a custom kernel, you should update your local sources and
rebuild world and the kernel. You should not use freebsd-update which is
not the right tool for customized kernels and environments (because you
deviate from the standard, which you likely have a good reason for).

So, option 2) should apply to you after updating your local checked out
sources..

Please let me know if I can be of more help wrt. this issue (no need to
send this to the entire list :))

Cheers
Remko

 
   Zoran
 
 ___
 freebsd-security@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-security
 To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

-- 

/\   Best regards,  | re...@freebsd.org
\ /   Remko Lodder   | remko@EFnet
 Xhttp://www.evilcoder.org/  |
/ \   ASCII Ribbon Campaign  | Against HTML Mail and News



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: NTP security hole CVE-2013-5211?

[Remko Lodder]

On 21 Mar 2014, at 11:41, Info / RIT.lt i...@rit.lt wrote:

 Dear FreeBSD users, my first experience with FreeBSD was 14 years ago, but 
 due to hardware problems I chose Linux. After working with Linux for 14 
 years, I decided to give a shot to FreeBSD again. After setting up FreeBSD 
 server with jails, I became a victim of DDoS which was launched from my 
 dedicated server, investigation led to NTP server, this misconfiguration left 
 with default settings shocked me, please fix this configuration bug.
 
 Firewall is for filtering traffic, but not for hiding buggy configs.
 
 Regards,
 Mindaugas Bubelis

I kept silent so far, but this lets me frown a bit.

We all know that there are people on the internet that try to hurt our 
businesses, 24*7*365.
All unprotected networks and hosts are targeted, 24*7*365.

It is -very- common practise to setup a security perimeter, to only allow 
traffic you want to have to your machine(s)
and only let out traffic you want from your machine(s). I worked for large 
scale ISP’s, and we all did the same.

Reading the mails from this thread leads me to believe that there is no 
stateful firewall concept in place?

Only allow the network you want to your NTP server(s) and deny the others.
Only let our your NTP server’s to the internet to retrieve the date.

Do that statefully and only traffic you send out should come back with the last 
line mentioned, it is hard from the internet seen
to hijack such a session and fool the firewall from letting the packet back in 
to your NTP server.

In my believing it is so that if you do not filter traffic, you are making a 
deliberate choice to let everyone smack your service(s).
That is not a problem but you also need to modify your configuration(s) to make 
sure it is as safe as it gets. We (FreeBSD) updated
the ntpd.conf file that is shipped as a Security Patch so that users running 
our update facilities have that in place. However since
people also change their configurations on their own or do not use that, they 
need to be aware that they need to update the rules as
well! We do not want to enforce our configuration changes to users who might 
have a good reason for having an alternative setup!

The only thing I saw from Brett that might need investigation is the additional 
'disable monitor’, though would that break people’s
setup ? are people using that on purpose for some reason? Then we cannot 
enforce it, just advice that this might be an solution to
prevent issues.

In my understanding and believing, stateful firewalling your networks is the 
best option, making sure that only your own machines
or a selected set of machines can access NTP resources on your network (or the 
internet, whatever you prefer) and that traffic
leaving your borders can only return if the firewall sees that you setup the 
communication in the first place.

In the above case: did you install the FreeBSD-release and never updated? Then 
that is something -you- should have done. Installing
something via delivered media is always out of date and needs to be updated 
before first use.

Thank you.
Remko

 
 From: owner-freebsd-secur...@freebsd.org owner-freebsd-secur...@freebsd.org 
 on behalf of Brett Glass br...@lariat.org
 Sent: Friday, March 21, 2014 6:44 AM
 To: Micheas Herman; freebsd-security@freebsd.org
 Subject: Re: NTP security hole CVE-2013-5211?
 
 At 10:38 PM 3/20/2014, Micheas Herman wrote:
 
 While true, that does mean that amplification attacks are limited to being
 able to attack those ten machines.
 
 The amplifier/relay is also a victim, and can be completely disabled by the 
 attack
 if its link to the Net becomes saturated.
 
 --Brett Glass
 
 ___
 freebsd-security@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-security
 To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
 ___
 freebsd-security@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-security
 To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

-- 

/\   Best regards,  | re...@freebsd.org
\ /   Remko Lodder   | remko@EFnet
 Xhttp://www.evilcoder.org/  |
/ \   ASCII Ribbon Campaign  | Against HTML Mail and News



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: NTP security hole CVE-2013-5211?

[Remko Lodder]

On 21 Mar 2014, at 20:20, Ronald F. Guilmette r...@tristatelogic.com wrote:

 
 In message ad479a36-993d-442a-aa07-ab52d8198...@freebsd.org, 
 Remko Lodder re...@freebsd.org wrote:
 
 Reading the mails from this thread leads me to believe that there is no
 stateful firewall concept in place?
 
 I am not the poster to whom you were responding (i...@rit.lt), however
 speaking only for myself I will confess that yes, in my case at least,
 although I have used ipfw for many years, I have never (until now) found
 any compelling need to either understand or make use of any of ipfw's
 stateful capabilities.

Hi Ronald,

That is ‘fine’ ofcourse but makes you vulnerable to the ‘crap’ that is hitting
your doorway now. Rest assured that you are already doing a great step in at
least filtering your machines and as you demonstrate you are active on
the internet to get the information you need to do it properly. That is already
way better then a lot of other people.

A question that pops my mind: Do you think we (security people) needed to be
more verbose about why this might have been a good idea? or could we have
done a better job in reasoning why stateful has it’s advantages?

 
 In my believing it is so that if you do not filter traffic, you are
 making a deliberate choice to let everyone smack your service(s).
 
 I personally *do* most certainly filter traffic, and have done, since
 I first connected *any* machine of mine to the Internet.  I can assure
 yoy that I never made any deliberate choice to let everyone smack me
 around.  Nontheless, that clearly did happen, eventually, when evil-doers
 decided, relatively recently, to use  abuse me as an NTP reflector, but
 my participation in this was not in any sense deliberate on my part, and
 arose strictly out of ignorance, for which I am suitably humbled and
 apologetic.

Let me offer my apologies, I did not want to make you feel ignorant or anything.

What I meant is that everyone should filter on their machines, or if possible
even ahead of their machines at the gateways. Stopping traffic you do not want
should occur at the border so that it never ever reaches the machines it is not
supposed to reach.

People do make a living in ‘pestering’ you and I (and many others) and now
smacking your NTP server(s) is gaining them something, or they wouldn’t just
do it.

My best advice in this case might be that only allowing in the networks you
want to have in on your NTP server (Stateful) prevents people that you do not
want to have their in the first place. Only letting out the traffic you want
(also stateful) prevents bogus replies because they most likely are caught at
the firewall already.

Ofcourse the software should be well protected as well, and secteam@ did his
best to offer the best solution possible. Though as mentioned by Brett for
example we just cannot force the update of ntpd.conf on user machines because
every admin could have legitimate reasons for having a configuration in place
they decided to have. It’s risky to change those things and especially enforce
them on running machines. Most of his ideas were in the advisory already
except for the ‘disable monitor’ part, which might be reason to discuss
whether that makes sense or not.

Thank you,

Remko

 
 
 Regards,
 rfg
 ___
 freebsd-security@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-security
 To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

-- 

/\   Best regards,  | re...@freebsd.org
\ /   Remko Lodder   | remko@EFnet
 Xhttp://www.evilcoder.org/  |
/ \   ASCII Ribbon Campaign  | Against HTML Mail and News



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Portaudit build currently broken

[Remko Lodder]

On Apr 4, 2013, at 12:20 AM, Mark Andrews ma...@isc.org wrote:

 
 In message 
 cac8hs2hruxmk9-49jjdk0spy_n-pjcelqqqyyokursyuj3a...@mail.gmail.com
 , Simon L. B. Nielsen writes:
 Hey,
 
 Just wanted to let people know that the portaudit build is currently
 broken resulting in changes to VuXML not getting propagated to
 portaudit (and pkg audit).
 
 I hope to get this fixed within a couple of days, and will follow up
 once it's working again.
 
 PS. the is a fallout of turning off ports SVN - CVS export. It was
 previously missed that this (yet another automated system we run)
 needed to be updated as well.
 
 What's more critical turning off SVN - CVS or timely security
 alerts?  Turn SVN - CVS back on, fix portaudit, then try turning
 SVN - CVS back off.
 

If we need to do something with the services anyway we can as well better do it 
the proper
way right away instead of turning on unsupported services

Thanks,
Remko


-- 
/\   With kind regards,| re...@elvandar.org
\ /   Remko Lodder  | re...@freebsd.org
XFreeBSD| http://www.evilcoder.org
/ \   The Power to Serve| Quis custodiet ipsos custodes



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Reasonable expectations of sysadmins (was Re: FreeBSD Security Advisory FreeBSD-SA-11:05.unix)

[Remko Lodder]

On Oct 2, 2011, at 6:11 AM, Mike Brown wrote:

 Chris Rees wrote:
 Generally users are expected to pay attention to what is updated-- I
 know this isn't always the easiest task, but blindly following
 instructions is not something that is generally advocated in FreeBSD.
 
 Generally, yes. For a security advisory, though, I don't think it's 
 unreasonable for the reader to expect that the solutions and workarounds are 
 exactly as described, with nothing left out or assumed that every system 
 administrator will know. Likewise, the advisory issuer surely expects that 
 the 
 instructions they provide *will* be very strictly followed.
 
 Based on my own experience, I did happen to realize that a reboot would 
 probably be needed, but since one procedure in the advisory said to reboot 
 and 
 the other didn't, it led me to wonder if maybe there was some magic in 
 freebsd-update that obviated the need for a reboot. Apparently there's not; 
 it 
 was just an oversight in the instructions.
 
 Also, sometimes things go haywire after a reboot, especially after extended 
 uptime and updates to the kernel or core libraries, so I'm in the habit of 
 only shutting down when necessary. So if I don't see and then reboot in an 
 update procedure - and most of the time, security updates don't require it - 
 then I don't do it.
 


Hi Mike,

I do see the point you are mentioning and I will discuss this the next time we 
(Security Team)
are preparing an advisory.

Thanks
Remko

-- 
/\   With kind regards,| re...@elvandar.org
\ /   Remko Lodder  | re...@freebsd.org
XFreeBSD| http://www.evilcoder.org
/ \   The Power to Serve| Quis custodiet ipsos custodes

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: It's not possible to allow non-OPIE logins only from trusted networks

[Remko Lodder]

 
 
 Yes, that's right. That would solve a whole lot of other problems too.
 It's true that I'm using SSH in many cases just as an easy to administer
 VPN. I've been postponing that for years. But I would need something
 that worked with FreeBSD and Gentoo (don't want to learn two tools) and
 for any client.



so with the pfsense project we have this thing integrated that is called 
OpenVPN.
Hell, I use it between multiple FreeBSD boxes to create a 'secure' (quotes 
because
it's as secure as possible in this world :)) network between them. I pushed it 
to my
parents who are (sigh) using Windows, I use it from my Mac (Viscosity) and hell
it even works on Linux/Gentoo..

And it's all.. free :-)

Cheers
Remko

-- 
/\   Best regards,| re...@freebsd.org
\ /   Remko Lodder  |
Xhttp://www.evilcoder.org/| Quis custodiet ipsos custodes
/ \   ASCII Ribbon Campaign| Against HTML Mail and News




___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: online cheksum verification for FreeBSD

[Remko Lodder]

On Mar 18, 2010, at 8:19 PM, Elmar Stellnberger wrote:
 

One can donate funds to the FreeBSD Foundation and submit a proposal to get 
this included.
Since we are all volunteers this might be something that isn't going to see the 
light soon.
You could ofcourse install something like tripwire and get a baseline from a 
trusted CD (you can
verify the ISO Files that we deliver) and use that to build your system.

Thanks,
Remko
(Speaking for myself)

-- 
/\   Best regards,| re...@freebsd.org
\ /   Remko Lodder  | re...@efnet
Xhttp://www.evilcoder.org/|
/ \   ASCII Ribbon Campaign| Against HTML Mail and News

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: freebsd-update not pulling in BIND update

[Remko Lodder]

On Tue, July 15, 2008 1:39 am, Mark Boolootian wrote:

 Hi folks,

 I ran freebsd-update today hoping it would have picked
 up the BIND upgrade.  freebsd-update reported:

   The following files will be updated as part of updating to
 7.0-RELEASE-p3:
   /boot/kernel/kernel
   /boot/kernel/kernel.symbols
   /usr/bin/dig
   /usr/bin/host
   /usr/bin/nslookup
   /usr/bin/nsupdate
   /usr/include/netinet/tcp.h
   /usr/lib/libssh.a
   /usr/lib/libssh.so.4
   /usr/lib/libssh_p.a
   /usr/sbin/dnssec-signzone
   /usr/sbin/lwresd
   /usr/sbin/named
   /usr/sbin/named-checkconf
   /usr/sbin/named-checkzone
   /usr/sbin/named-compilezone
   /usr/sbin/sshd
   /usr/src/sys/conf/newvers.sh
   /usr/src/sys/netinet/tcp.h
   /usr/src/sys/netinet/tcp_output.c

 While there is a new file for /usr/sbin/named, it isn't reporting
 the updated version:

 $ /usr/sbin/named -v
 BIND 9.4.2

 Any thoughts?

 thanks in advance,
 mark
 ___

From my understand we don't bump the version of the named binary, so that
seems correct..

-- 
/\   Best regards,  | [EMAIL PROTECTED]
\ /   Remko Lodder   | [EMAIL PROTECTED]
 Xhttp://www.evilcoder.org/  |
/ \   ASCII Ribbon Campaign  | Against HTML Mail and News


___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: BIND update?

[Remko Lodder]

On Wed, July 9, 2008 5:19 pm, Josh Mason wrote:
 Remko Lodder wrote:
 On Tue, July 8, 2008 8:34 pm, Andrew Storms wrote:
 Are going to expect a update for BIND today?

 http://www.isc.org/index.pl?/sw/bind/bind-security.php

 ___

 Hello,

 I think it's important that we do not overstretch things instantly. The
 FreeBSD Security Team is aware of this situation and will investigate
 how
 to do plan and act upon this.

 Thanks,
 Remko


Hello Josh,

  Right, lets not act swiftly. That would be too much to ask. Is there any
 reason why FreeBSD is one of the last vendors to release patches for the
 vulnerability?

Thanks for taking the time to reply to the thread. Sadly the tone you are
using makes me feel a bit sad. There is a deeper reply in the reply you
send, and I do not like it. We as the Security Team do our best to act as
soon as possible on things. Items like these tend to take up a lot of time
and resources, we need to test things properly, make sure all the bits and
bytes are OK, so that we don't make people grumpy about things we
overlook. I am sure you can understand that and leave away the attitude.


 I apologize, perhaps I should simply do it myself as has been the common
 response as of late, or perhaps install from source retrieved from
 isc.orgshould be the expected answer?

If you want to do that, no one will be stopping you. We as the security
team will be working as hard as possible to try and understand the
problem, wrap up the correct response and make sure it gets fixed where
needed, these things just take time.


 Most other vendors seem to have taken this seriously, yet FreeBSD seems to
 be sitting on their hands for some unknown reason while its users remain
 vulnerable.

We also take this seriously, I think you are short-visioned by telling
something like this. There is a mitigation strategy for the BIND issue as
already reported on the list. Given your response you must be clever
enough to find it.


 Thanks for all the hard work,

Thanks for the deeper attitude and the email. I hope you can understand
that we are a volunteer organisation which does not have paid people
working on items 24/7 which other vendors might have. If you want to have
that, I am sure we can get some people so far for getting payed for their
normal wages so that we can do that as well. Till that time you should
understand volunteer organisations better, or come up with a better
proposal you simply don't know how much is involved here.


Your incredibly loyal follower


Sarcastic.

-- 
/\   Best regards,  | [EMAIL PROTECTED]
\ /   Remko Lodder   | [EMAIL PROTECTED]
 Xhttp://www.evilcoder.org/  |
/ \   ASCII Ribbon Campaign  | Against HTML Mail and News


___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: BIND update?

[Remko Lodder]

Josh Mason wrote:

Thanks, you really showed how you are by sending these replies. I wish 
you goodluck with your quest, perhaps someday someone can help you.


Goodbye.

--

/\   Best regards,  | [EMAIL PROTECTED]
\ /   Remko Lodder   | [EMAIL PROTECTED]
 Xhttp://www.evilcoder.org/  |
/ \   ASCII Ribbon Campaign  | Against HTML Mail and News
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: BIND update?

[Remko Lodder]

Remko Lodder wrote:

Josh Mason wrote:

Thanks, you really showed how you are by sending these replies. I wish 
you goodluck with your quest, perhaps someday someone can help you.


Goodbye.



Hi,

I am sorry for this reply, it was an expression of my frustation towards 
you. The frustation is just easily generated by people demanding support 
from volunteers, that are trying to service you and others in their own

spare time. Time that they can also spend on different items, yet we
crazy people decide to work on a Free Operating System, getting nothing
payed for it, only happy users (Where possible) around us.

I think you can understand my frustration, because I think you would 
reply the same if someone demanded even more free time from you.


I hope you can understand this.

//Remko
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: BIND update?

[Remko Lodder]

Wesley Shields wrote:

On Wed, Jul 09, 2008 at 01:27:06PM -0400, Josh Mason wrote:

On 7/9/08, Remko Lodder [EMAIL PROTECTED] wrote:

Remko Lodder wrote:

Josh Mason wrote:

Thanks, you really showed how you are by sending these replies. I wish you

goodluck with your quest, perhaps someday someone can help you.

Goodbye.



Hi,

I am sorry for this reply, it was an expression of my frustation towards
you. The frustation is just easily generated by people demanding support
from volunteers, that are trying to service you and others in their own
spare time. Time that they can also spend on different items, yet we
crazy people decide to work on a Free Operating System, getting nothing
payed for it, only happy users (Where possible) around us.

I think you can understand my frustration, because I think you would reply
the same if someone demanded even more free time from you.

I hope you can understand this.

//Remko


I completely understand and took no offence from your previous email -
I know I am being confrontational. I myself have been in that position
many a time before and know exactly how it feels. Unfortunately that
doesn't negate the responsibility of the security team to produce
patches quickly.

The initial response of the sec team is aware of the situation and
will investigate was basically just fluff. If you weren't already
aware of it you aren't much of a sec team. What is needed is an
expected delivery. I would say considering the nature of the exploit
but honestly that shouldn't change anything at all. If the delivery
isn't going to be immediate there should always be an ETA provided. If
for nothing else other than so your users can plan around it (i.e.
this is too long I need to take action myself - or X time or date
is sufficient I'll wait for the official release and apply it then).
Without that people are twiddling their thumbs wondering if there is
ever going to be one.


You have a good point there.  I'm not aware of any page which describes
the current issues under investigation by the security team.  If such a
thing does not exist I think it would be a good thing to have,
especially if it details rough timelines for things.  By that I mean
recording historic information and expected information (we received
notification on this date, we expect to have a final advisory on this
date).

In the security world there is a balance which must be maintained
between providing information to consumers so that they may plan
accordingly, and not providing too much information so that the
attackers can write exploits; this is the sensitive nature of the
information which often leads to opaque processes by security teams
around the world.  There is the case where full details are released
without advance notice to the vendors/projects, in which case the
balance has been lost from the start.

Remko, do you - or anyone else - on the security team have any thoughts
on this?  I'd be willing to step up and keep a wiki page (or something
else) up to date with the information.

-- WXS


There will be no such page with information about pending items. 
Sometimes we are bound to non-disclosures etc. We handle this internally
and will continue to do so. If people cannot live with that (like Josh) 
then that's their challenge.


Note I speak largely for myself in this case. I am not going to support 
a wiki page or something. I do not know what the other secteam members 
think about that, but I expect something like my opinion.


//Remko

--

/\   Best regards,  | [EMAIL PROTECTED]
\ /   Remko Lodder   | [EMAIL PROTECTED]
 Xhttp://www.evilcoder.org/  |
/ \   ASCII Ribbon Campaign  | Against HTML Mail and News
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: BIND update?

[Remko Lodder]

Wesley Shields wrote:

There will be no such page with information about pending items. 
Sometimes we are bound to non-disclosures etc. We handle this internally
and will continue to do so. If people cannot live with that (like Josh) 
then that's their challenge.


Note I speak largely for myself in this case. I am not going to support 
a wiki page or something. I do not know what the other secteam members 
think about that, but I expect something like my opinion.


That's certainly a fair statement.  I understand the non-disclosure
aspect of the situation, but I also feel a more transparent process
where ever possible is a good idea.  I suspect more thought on the
matter is necessary.

-- WXS


I think we can better spend time on improving VuXML entries then 
spending more time on considerations of this topic. Please close it and 
move along.


--

/\   Best regards,  | [EMAIL PROTECTED]
\ /   Remko Lodder   | [EMAIL PROTECTED]
 Xhttp://www.evilcoder.org/  |
/ \   ASCII Ribbon Campaign  | Against HTML Mail and News
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]

[Fwd: cvs commit: ports/dns/bind9 Makefile distinfo ports/dns/bind94 Makefile distinfo ports/dns/bind95 Makefile distinfo]

[Remko Lodder]

Dear all,

Doug just updated the ports tree with the updated BIND ports. If you 
urgently want to upgrade and really cannot wait for the advisory. Please 
use the ports system to get up to speed.


Thanks Doug for working on this on such short notice!

Cheers,
remko

 Original Message 
Subject: cvs commit: ports/dns/bind9 Makefile distinfo ports/dns/bind94 
Makefile distinfo ports/dns/bind95 Makefile distinfo

Date: Wed, 9 Jul 2008 19:02:01 + (UTC)
From: Doug Barton [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]

dougb   2008-07-09 19:02:01 UTC

  FreeBSD ports repository

  Modified files:
dns/bind9Makefile distinfo
dns/bind94   Makefile distinfo
dns/bind95   Makefile distinfo
  Log:
  Upgrade to the -P1 versions of each port, which add stronger 
randomization

  of the UDP query-source ports. The server will still use the same query
  port for the life of the process, so users for whom the issue of cache
  poisoning is highly significant may wish to periodically restart their
  server using /etc/rc.d/named restart, or other suitable method.

  In order to take advantage of this randomization users MUST have an
  appropriate firewall configuration to allow UDP queries to be sent and
  answers to be received on random ports; and users MUST NOT specify a
  port number using the query-source[-v6] option.

  The avoid-v[46]-udp-ports options exist for users who wish to eliminate
  certain port numbers from being chosen by named for this purpose. See
  the ARM Chatper 6 for more information.

  Also please note, this issue applies only to UDP query ports. A random
  ephemeral port is always chosen for TCP queries.

  This issue applies primarily to name servers whose main purpose is to
  resolve random queries (sometimes referred to as caching servers, or
  more properly as resolving servers), although even an authoritative
  name server will make some queries, primarily at startup time.

  This update addresses issues raised in:
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1447
  http://www.kb.cert.org/vuls/id/800113
  http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience

  Revision  ChangesPath
  1.82  +2 -2  ports/dns/bind9/Makefile
  1.44  +6 -6  ports/dns/bind9/distinfo
  1.85  +2 -3  ports/dns/bind94/Makefile
  1.47  +6 -6  ports/dns/bind94/distinfo
  1.87  +2 -2  ports/dns/bind95/Makefile
  1.49  +6 -6  ports/dns/bind95/distinfo
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]

--

/\   Best regards,  | [EMAIL PROTECTED]
\ /   Remko Lodder   | [EMAIL PROTECTED]
 Xhttp://www.evilcoder.org/  |
/ \   ASCII Ribbon Campaign  | Against HTML Mail and News
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: VuXML entry for CVE-2008-0318 (libclamav)

[Remko Lodder]

On Thu, February 14, 2008 4:10 pm, Eygene Ryabinkin wrote:
 Good day.

 Wed, Feb 13, 2008 at 06:38:46PM +0300, Eygene Ryabinkin wrote:
 Attached is the draft of the VuXML entry for the new ClamAV
 vulnerability.

 As pointed to me by Remko Lodder, the attachment was stripped.
 Resending it inline.

 Remko, thanks again for pointing me to this pity fact!


Hey,

I had processed it to VuXML just minutes ago, thanks for your submission!
(no worries about the stripped attachement!) it's greatly appreciated!

Cheers
remko

-- 
/\   Best regards,  | [EMAIL PROTECTED]
\ /   Remko Lodder   | [EMAIL PROTECTED]
 Xhttp://www.evilcoder.org/  |
/ \   ASCII Ribbon Campaign  | Against HTML Mail and News


___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: portaudit: xfce vulnerabilities

[Remko Lodder]

On Wed, February 13, 2008 2:42 pm, Andriy Gapon wrote:

 It seems that there is a mistake on this page:
 http://www.freebsd.org/ports/portaudit/024edd06-c933-11dc-810c-0016179b2dd5.html

 All reference URLs say that the vulnerability existed before version
 4.4.2 and it is fixed in version 4.4.2.
 But affected version are described as:
 xfce4-panel 4.4.1_1
 libxfce4gui 4.4.1_1

 Shouldn't there be equal or less instead of greater?

 --
 Andriy Gapon
 ___

Hey Andriy,

Thanks for the report, from what I know miwi was going to look at this to
match lt4.4.2/lt so that nothing else is affected..

Cheers
remko

-- 
/\   Best regards,  | [EMAIL PROTECTED]
\ /   Remko Lodder   | [EMAIL PROTECTED]
 Xhttp://www.evilcoder.org/  |
/ \   ASCII Ribbon Campaign  | Against HTML Mail and News


___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]

RE: What about FreeBSD? - KAME Project ipcomp6_input() Denial of Service

[Remko Lodder]

We are aware and working on resolving this.

Thanks
Remko
Hat: freebsd secteam

-Original Message-
From: Mohacsi Janos [EMAIL PROTECTED]
To: freebsd-security@freebsd.org
Sent: 6-2-08 21:54
Subject: What about FreeBSD? - KAME Project ipcomp6_input() Denial of Service 


TITLE:
KAME Project ipcomp6_input() Denial of Service

CRITICAL:
Moderately critical

IMPACT:
DoS

WHERE:
From remote

DESCRIPTION:
A vulnerability has been reported in the KAME Project, which can be
exploited by malicious people to cause a DoS (Denial of Service).

The vulnerability is caused due to an error within the
ipcomp6_input() function in kame/sys/netinet6/ipcomp_input.c when
processing IPv6 packets with an IPComp header. This can be exploited
to crash a vulnerable system by sending a specially crafted IPv6
packet.

SOLUTION:
Fixed in the CVS repository.
http://www.kame.net/dev/cvsweb2.cgi/kame/kame/sys/netinet6/ipcomp_input.c.diff?r1=1.36;r2=1.37

PROVIDED AND/OR DISCOVERED BY:
US-CERT credits Shoichi Sakane.
NetBSD credits the Coverity Prevent analysis tool.

ORIGINAL ADVISORY:
US-CERT VU#110947:
http://www.kb.cert.org/vuls/id/110947

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: OpenSSL bufffer overflow

[Remko Lodder]

Stefan Esser wrote:
 I did not see any commits to the OpenSSL code, recently; is anybody
 going to commit the fix?
 
 See http://www.securityfocus.com/archive/1/480855/30/0 for details ...
 
 Regards, STefan

Hello Stefan,

We are aware of the situation and have this on our todo list.

Thanks,
Remko

-- 
Kind regards,

 Remko Lodder   ** [EMAIL PROTECTED]
 FreeBSD** [EMAIL PROTECTED]

 /* Quis custodiet ipsos custodes */
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: [tt #17465] [Comment] FreeBSD Security Advisory FreeBSD-SA-07:06.tcpdump

[Remko Lodder]

WebaZilla - Support [kv] wrote:
 Bezruk wrote:
 This is a comment.  It is not sent to the Requestor(s):

 On Thu Aug 02 18:39:00 2007, kv wrote:
 Если возле компа, посмотри плиз, на duty dhcpd я опустил, а подниматься 
 он вообще не хочет. В логах полная тишина, я подозреваю, это из-за 
 каких-то вопросов с безопасностью на этом сервере.

 А че было-то?
 
 логическая ошибка
 
 


So, this is an english text, what was above?

-- 
Kind regards,

 Remko Lodder   ** [EMAIL PROTECTED]
 FreeBSD** [EMAIL PROTECTED]

 /* Quis custodiet ipsos custodes */







___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Support for 5.x (Was: Re: What about BIND 9.3.4 in FreeBSD in base system ?)

[Remko Lodder]

On Tue, Feb 06, 2007 at 04:08:11PM +0100, Julian H. Stacey wrote:
 Remko Lodder wrote:
  On Tue, Feb 06, 2007 at 01:21:44PM +, Chris wrote:
   On 03/02/07, Julian H. Stacey [EMAIL PROTECTED] wrote:
   think you hit the nail bang on the head, I am one such person who
   tried to submit a bug causing crashes and have found a lack of
   enthusiasm to get the bug fixed.  One thing I have noticed about 6.x
   is there is many features that 5.x doesnt have, so it looks clear
   there is lots of activity in working on new code but little activity
   in fixing bugs and working on stability.
  
  Hello,
  
  I feel poked by this, and it saddens me that this is the reply we
  get. 
 
 No criticism intended of the folk who sacrifice their free time
 dealing with other people's bug reports  diffs, it's very kind of
 them to do it :-) I guess lots of us paused a moment to admire the
 courage of the last bug-a-thon assault team (a weekend about a month
 back I recall).
 
 I just suggest the oldest bug reports (most boring/ intractable/
 tedious, unappealing to unpaid volunteers) could be worked by
 paid/sponsored help, if there's every any money or sponsored hours
 available, leaving the newer bugs to interest the unpaid volunteers.
 

Well, given my  track-record for the bugs, you can see that I and
some other committers try to wreak-havoc under the old PR's. This isn't
always simple and trivial to do, getting feedback takes ages from time
to time (logical because the submitter feels annoyed that it took so
long to get a reply at all) and then you need to find someone to fix
this. It will go, steadily, but will always take time, which is
crucial, even for paid people.

I hope that the incoming current flow is also seen and that new
tickets are handled better then the old ones (we do in my eyes).
Currently all the new PR's are analyzed by one of the bugmeisters
(as far as I know that is) and obscure ones and support questions
are discarded immediatly; we try to get more feedback on unclear
tickets, and try to assign new tickets that are not grabbed
by someone within X time to a committer working in that region.

Improvements are there; paid support would help; but it remains
a question of time (even money cannot make up most of the things
since one needs to be very allround to work through all the
tickets that are ancient^Wstale^Wstill there, oh well you get
the idea).

Thanks for the feedback though!

Remko

-- 
Kind regards,

 Remko Lodder   ** [EMAIL PROTECTED]
 FreeBSD** [EMAIL PROTECTED]

 /* Quis custodiet ipsos custodes */
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Recent vulnerabilities in xorg-server

[Remko Lodder]

On Thu, Jan 11, 2007 at 09:41:57AM +0300, Eygene Ryabinkin wrote:
 Colin, good day!
 
 Spotted two patches for x11-servers/xorg-server port: see entries for
 x11r6.9.0-dbe-render.diff and x11r6.9.0-cidfonts.diff at
 http://xorg.freedesktop.org/releases/X11R6.9.0/patches/index.html
 Seems like they are not applied to the xorg-server-6.9.0_5. May be
 it should be added to the VuXML document?
 
 There is a ports/107733 issue that incorporates these patches. May
 be you should have a look.
 
 Thanks!
 -- 
 Eygene

Goodmorning Eygene,

Thanks for the notification! We are kinda busy at the
moment, so if you could spare a minute and write a
VuXML entry (a draft would also suffice), we can
more easily add it. If you are unable to do so, no
probs, but it is likely to take a bit longer to
get the things incorporated.

Thanks for using FreeBSD and your willingness to improve
the product! It is being appriciated.

Cheers,
Remko

-- 
Kind regards,

 Remko Lodder   ** [EMAIL PROTECTED]
 FreeBSD** [EMAIL PROTECTED]

 /* Quis custodiet ipsos custodes */
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: ports / www/linux-seamonkey / flashplugin vulnerability

[Remko Lodder]

R. B. Riddick wrote:

Hi!

Since linux-flashplugin7 r63 is vulnerable according to
  http://vuxml.FreeBSD.org/7c75d48c-429b-11db-afae-000c6ec775d9.html
isn't www/linux-seamonkey vulerable, too (it seems to include 7 r25)?

Bye
Arne



Hi Arne,

We will look into this asap and give you proper feedback when we
have it.

Thanks for the notice!

Cheers,
Remko
on behalf of The FreeBSD Security Team


--
Kind regards,

 Remko Lodder   ** [EMAIL PROTECTED]
 FreeBSD** [EMAIL PROTECTED]

 /* Quis custodiet ipsos custodes */
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Ruby vulnerability?

[Remko Lodder]

Sergey Matveychuk wrote:

Shaun Amott wrote:

On Fri, Jul 28, 2006 at 03:03:43PM +1000, Joel Hatton wrote:

FYI, Red Hat released an advisory today about a vulnerability in Ruby. So
far it doesn't appear in the VuXML, but am I correct in presuming it will
soon?


I've added it; thanks for the report.



Can we get patches somewhere? I can't find any.



It is said that the patches are available through the CVSweb
but all the information I could fine was in japanese, which is
a bit difficult to read for me (read: i do not speak nor read
japanese at all).

We might have a shot on how different vendors resolved this
issue and generate patches from that..

--
Kind regards,

 Remko Lodder   ** [EMAIL PROTECTED]
 FreeBSD** [EMAIL PROTECTED]

 /* Quis custodiet ipsos custodes */
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: ports/84312: security/portaudit doesn't report about all security bugs

[Remko Lodder]

Synopsis: security/portaudit doesn't report about all security bugs

Responsible-Changed-From-To: freebsd-security-remko
Responsible-Changed-By: remko
Responsible-Changed-When: Sat Jul 30 17:05:19 GMT 2005
Responsible-Changed-Why: 
I entered the apache vulnerability into VuXML so i should fix this.
Thanks for mentioning this!

http://www.freebsd.org/cgi/query-pr.cgi?pr=84312
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]