Re: CA's TLS Certificate Bundle in base = BAD

[Roger Marquis]

After running a 12.4 installworld found TrustCor certs had been
reinstalled.  Out of curiosity, were these known bad certificates
intentionally left in RELEASE?  If so it does appear we could use a
ports-based solution.  At this point all the port would need to do is
periodically "rm /usr/share/certs/trusted/TrustCor*" but there's sure to
be room for options to better harden PKI.

Roger Marquis

Re: FreeBSD Security Advisory FreeBSD-SA-22:15.ping

[Roger Marquis]

Also note that the update can be as easy as:

  gitup src
  cd /usr/src
  make buildworld
  cd sbin/ping
  make install
  ls -l /sbin/ping
  /sbin/ping ...

Roger Marquis



On Wed, Nov 30, 2022 at 05:03:10PM -0500, mike tancsa wrote:

On 11/30/2022 4:58 PM, Dev Null wrote:


Easily to exploit in a test environment, but difficult to be exploited
in the wild, since the flaw only can be exploited in the ICMP reply,
so the vulnerable machine NEEDS to make an ICMP request first.

The attacker in this case, send a short reader in ICMP reply.


Lets say you know that some device regularly pings, say 8.8.8.8 as part
of some connectivity check. If there is no stateful firewall, can the
attacker not just forge the reply on the chance their attack packet
could get there first ??? Or if its the case of "evil ISP" in the middle,
it becomes even easier. At that point, how easy is it to actually do
some sort of remote code execution. The SA implies there are mitigating
techniques on the OS and in the app.?? I guess its that last part I am
mostly unclear of, how difficult is the RCE if given the first
requirement as a given.


It's probably also worth considering it as a local privilege escalation
attack.  The attacker will need to control a ping server, but it's often
the case that enough ICMP traffic is allowed out for that to work and in
that case they have unlimited tries to defeat any statistical mitigations
(unless the admin spots all the ping crashes).

-- Brooks

Re: sysrc bug

[Roger Marquis]

Also, changing the root shell is bad for many reasons and I'm not
surprised that something doesn't work.


Surprised this old myth is still being repeated.  Having used various
root shells in FreeBSD and other Unux/Linux systems for decades I have to
ask specifically what said reasons are, particularly considering
/usr/sbin/sysrc starts with "#!/bin/sh" (as does and should every system
shell script).

Roger Marquis
___
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"

Re: Security leak: Public disclosure of user data without their consent by installing software via pkg

[Roger Marquis]

Whatever the fix I hope we all agree that a policy is needed allowing or
requiring the ports and security teams to reject ports and patches which
exfiltrate (i.e, upload) _any_ local information without an explicit,
detailed and robust opt-in.

Roger Marquis




On 08/04/2021 18:24, Shawn Webb wrote:

[..]


1. Ad hominem much? I understand the underlying problem very well.
2. Your hostility is incredibly annoying.
3. You attribute malice where there is none.
4. This is volunteer work, where volunteers have everyones well-being
in mind.
5. Threatening to go to journalists accomplishes... what? What makes
you think journalists are NOT paying attention to this list? What
makes you think journalists care about you?
6. I really, really, really, really, really hate the "Karen" meme. But
it fits incredibly well here.
7. Where can I review your patches that fix the problem?


To be honest, the original post contained link to PR 251152 where Steve Wills 
posted patch 2020-12-07. What more patch is needed? The same patch again?

The fix was not committed for a 5 months
The sending of the data is not unintentional as the maintainer stated in his 
comment #13 from 2020-12-29


Even the code in periodic/monthly/300.statistics is written in "very unusual 
way". There are cases with 3 switches:

if YES = run it
if NO = tell user to enable it
if anything else = run it

Is this how all periodic scripts should behave? I don't think so. It should 
run if _enable="YES" and be silent in any other case.


Again - the first patch was provided 5 months ago by Steve Wills and the 
problem was not fixed to this day because maintainer thinks there is nothing 
to fix.


Your first jump in this thread with "lolwut" reaction was very far from 
expected. Trying to neglect the problem, trying to say that FreeBSD is not 
responsible for how packages behave in install time and nobody should be 
upset that something sends data on install time...


Kind reagards
Miroslav Lachman


8. Entitlement mentality much?

Sure, the bsdstats package shouldn't submit just on "pkg install."
Instead of fixing the problem, you went the hostile route.

I'm sure you won't learn anything from this, but I hope you do. To me,
it reinforces how random people feel entitled to force their will on
others.

Thanks,



___
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"


___
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"

Re: Buffer overruns, license violations, and bad code: FreeBSD 13s close call

[Roger Marquis]

Surprised there's been no mention of wireguard in this list,
particularly given the threads on other forums.  That said it is
good to finally have a third-party analysis of the issue.  See
today's Ars Technica for Jim Salter's take:

 
<https://arstechnica.com/gadgets/2021/03/buffer-overruns-license-violations-and-bad-code-freebsd-13s-close-call/3/>

The only downside, no idea how it got by Ars' editors, is an
irrelevant side-thread on 'Macy's record as a landlord.  That
aside the article is a must-read for anyone concerned with
FreeBSD security.

Roger Marquis
___
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"

Re: Moinmoin

[Roger Marquis]

Hey Kubilay,

Originally saw the vuln on a security RSS feeds, probably NIST's, but it
is also listed on the moinmo.in website:

  News

2020-11-08 MoinMoin 1.9.11 released, including urgent security
fixes! See: https://github.com/moinwiki/moin-1.9/releases/tag/1.9.11

Roger



On 28/11/2020 12:55 pm, Roger Marquis wrote:

Anyone know if www/moinmoin is abandonware?  The maintainer is listed as
pyt...@freebsd.org and the version in ports has had an unpatched
vulnerability for the last couple of weeks.



Hi Roger,

I don't believe so, but development is slow

Can you point us to references for the vulnerability and/or any other 
references (cve, anouncements, commits, issues, patches in other OS's, etc)


./koobs

___
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"

Moinmoin

[Roger Marquis]

Anyone know if www/moinmoin is abandonware?  The maintainer is listed as
pyt...@freebsd.org and the version in ports has had an unpatched
vulnerability for the last couple of weeks.

Roger Marquis
___
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"

Re: A question about Security Advisories

[Roger Marquis]

The SMUP (single monolithic update procedure) was implemented several
years ago IIRC.  At the time it was explained that there were
insufficient staff resources to continue doing QA for incremental
builds, even ones as simple as usr.bin/gzip.  That said it is still just
as straightforward to it yourself.

What I wonder is why staff is so resource constrained?  Is it
fundamentally due to a broken funding model?  Are potential volunteers
turned away for not having submitted enough patches and other
questionable policy hurdles?   Are there other organizational reasons
why such burdensome upgrades are left for end-users?

A lot of this maintenance hassle will someday be resolved with base
packages but even that project has been resource constrained.  The
FreeBSD Foundation has not, to the best of my knowledge, commented on
these resource constraints or potential resolutions.  Quarterly and
Annual reports occasionally mention them but only in passing.  How 
do we get someone on the Board/Foundation who is willing and able to

prioritize these important issues?

Roger Marquis



 Hi,
Last years all Security Advisories regarding base system in the "update
your vulnerable system via a source code patch " section recommends to
rebuild a whole world instead of an affected part of a base system. This
is in a most cases an overhead.

For example 9 years old SA-11:04 [1] offers:

b) Execute the following commands as root:

# cd /usr/src
# patch < /path/to/patch
# cd /usr/src/usr.bin/compress
# make obj && make depend && make && make install
# cd /usr/src/usr.bin/gzip
# make obj && make depend && make && make install

What is a reason we stop to do it? I understand that the preferred way
now is a binary upgrade.


+1 I've been wondering this as well. What is the reason for it?
--
J.


___
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"

Re: Early heads-up: plan to remove local patches for TCP Wrappers support in sshd

[Roger Marquis]

In the interest of good logging it may be better to filter ssh attempts
with libwrap than with packet filtering.  The difference being that
libwrap logging, particularly when used with fail2ban, tends to be more
readable and parseable.

Not having libwrap in sshd is most simply and easily worked around, IMO,
by running it from inetd.  While less experienced sysadmins may not be
familiar with inetd, and some others believe it impacts session setup
time, 99.99% of sshd implementations will not see any difference between
sshd linked with libwrap vs unlinked and run under inetd.  Performance
might be an issue is when dozens or hundreds of sessions are received
per minute but then those sites are likely to already have load
balancing.

FreeBSD's inetd also has more instance and rate-limiting options than
libwrap or packet filtering.  I wouldn't be surprised if this was part 
of the reason why it is no longer bundled.


Roger Marquis



Upstream OpenSSH-portable removed libwrap support in version 6.7,
released in October 2014. We've maintained a patch in our tree to
restore it, but it causes friction on each OpenSSH update and may
introduce security vulnerabilities not present upstream. It's (past)
time to remove it.


So color me ignorant, but how does this affect things like DenyHosts? Or
is there an in-application way to block dictionary attacks? I can't go back
to having my servers pounded on day and night (and yes, I listed on an
alternative port).

___
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"

Re: Review of FreeBSD Security Advisory Process: Incl Heads Up, Dates, Etc [cont: 5599 SACK}

[Roger Marquis]

Peter Jeremy  wrote:

Security Officer is a volunteer position and their time is valuable.
requiring them to do more work to provide information


Problem is such communications are critical for end-users.

We all know the security teams are woefully over-burdened and
under-resourced but why argue for the status-quo?  Wouldn't it be better
to appoint a communications coordinator and/or actually PAY THE SECURITY
TEAMS so they can do the job without financial sacrifice.

Looking at items the FreeBSD Foundation funds which have no measurable
effect on the size of the user-base, and at the former BSD shops
converting to Linux because of security, I don't know, just seems like a
no-brainer from here.

Many years ago people recommended only updating ports which had security
advisories.  Now nobody recommends that.  Instead they recommend
updating with every patch and keeping an eye on NIST CVEs, Bugtraq and
Redhat, Debian and Ubuntu advisories.  Even following advisories via RSS
is, unfortunately, unsustainable overhead at most organizations.

A few years ago people recommended submitting vuxml entries when new
advisories came out.  Some of us did that and were surprised to find
that even remote exploit (CVE level 7+) reports could sit in the queue
for days or weeks.  Follow-ups would be met with the same "we're all
volunteers here".  Not surprisingly we (volunteer patch and vuxml
submitters) no longer do that either.

Perhaps this is tilting at windmills but wouldn't it be better to at
least try beefing-up security support and creating a sustainable
SECURITY BUDGET?  If it grew the user-base by only a few percent that
would at the very least make everyone's contribution more valuable.

IMO,
Roger Marquis
___
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"

Re: Untrusted terminals: OPIE vs security/pam_google_authenticator

[Roger Marquis]

In my case, no page is involved, just the FreeOTP app on my Android
phone (which is less convenient than a sheet of paper with OPIE
passwords, but I can live with that).


FreeOTP and FreeOTP+ are IMO the best OTP apps out there.  They require
no privacy invading "push" notifications and are open source.  Just wish
more sites would publish numeric codes instead of gimmicky QR codes.

That said there are still plenty of us who also use OPIE.  The passcodes
are a solid T/HOTP fallback, aren't subject to seizure by border agents
having a bad day, can be easily copied and stored on paper and have zero
dependencies on 3rd parties.

That's not to say that OPIE should be kept in base though.  There's
already way too much unused legacy cruft in FreeBSD base.  Ports are the
right tool for that job.

But OPIE is still used, can be updated relatively easily, and should be
kept somewhere accessible for security-conscious end-users.  To
eliminate it would only benefit those with commercial interests in
proprietary and hosted (vendor lock-in) MFA solutions.

IMO,
Roger Marquis
___
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"

Re: SQLite vulnerability

[Roger Marquis]

On Mon, 17 Dec 2018, Kubilay Kocak wrote:

Pretty close :)
Original source/announcement:
https://www.tenable.com/blog/magellan-remote-code-execution-vulnerability-in-sqlite-disclosed 
[December 14th, 2018]


Not original though Tenable may have based their announcement on:

  https://meterpreter.org/sqlite-remote-code-execution-vulnerability-alert/
  [December 11th, 2014]

I've already re-opened Issue #233712 [1], which was our databases/sqlite3 
port update to 3.26.0 and requested a merge to quarterly.


Thank you Kubila and thanks to pavelivol...@gmail.com who updated the sqlite3
port on December 4th.

Roger Marquis
___
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"

Re: SQLite vulnerability

[Roger Marquis]

Robert Simmons acerbically replied:

Since you may not read that essay on open source software, here is the
salient point for you:
  - For users: remember when filing an issue, opening a pull request or
  making a comment on a project to be grateful that people spend their free
  time to build software you get to use for free. Keep your frustrations and


The problem with Robert Simmons' line of reasoning:

 a) keeping vulxml up to date is a fixable problem, and

 b) ignoring the critical role of FreeBSD's security teams will only
result in FreeBSD boxes being hacked and end-users migrating to
Linux.

Considering the lack of technical or logical arguments being made
against, for example, larger security teams or security team funding
(after all, we're only talking about timely entries in the vulnerability
database) it would not be unreasonable to conclude that opposition
viewpoints are simply Linux advocates.

Roger Marquis
___
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"

Re: SQLite vulnerability

[Roger Marquis]

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


Apologies for being negative Remko, but isn't it the implications for
those running FreeBSD that are negative rather than someone pointing
them out?  Or do we have different interpretations of the scope or
threat profile of this particular issue?  (considering that sqlite has
been installed by default on every FreeBSD host and jail for a few years
now)


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.


This is a good answer to my question regarding what might be done to
address the gap in reporting.  I am in no position to financially
sponsor anyone but certainly the FreeBSD Foundation is.  Maybe someone
from the board could weigh-in regarding the feasibility of funding this
critical function?  According to
 more than $3M is
available, a small portion of which, if applied on an ongoing basis,
would bring FreeBSD up to the 3rd party application security standards
of its competitors (Android aside) and make the OS infinitely easier for
us to advocate, admin and develop for.

  On that note, does anyone on this list have experience applying for
  FreeBSD Foundation grants?  If so please contact me off-list.

OTOH it may also be a matter of team size and/or policies that would be
more effective in the short term.  Would be great if other sec team and
or board members could comment (ideally without shooting the messenger).


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.


I don't know Remko.  It seems like too far-reaching of an issue to
ignore.  Most of us don't see it as negative or positive but simply a
means of keeping end-users safe and making everyone's contribution to
the project more effective.

Roger Marquis
___
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"

SQLite vulnerability

[Roger Marquis]

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
___
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"

Re: Interim support guarantee for FreeBSD 12

[Roger Marquis]

FYI re potential cuts to STABLE long-term support.  Does this affect the
RELEASE branch as well?  Anyone know where this is being discussed?  The
announcement mentions community feedback but that seems unlikely given
there has been no mention of it on the freebsd-security list.

Roger Marquis



Date: Wed, 28 Nov 2018 11:04:48 -0400
From: FreeBSD Core Team Secretary 
To: freebsd-annou...@freebsd.org
Subject: [FreeBSD-Announce] Interim support guarantee for FreeBSD 12

Dear FreeBSD community,

The Core Team, in consultation with Release Engineering, the Security
Team, and Port Manager has decided that we need to reevaluate the 5-year
support of stable branches starting with stable/12.  A changed security
landscape, increased toolchain velocity, and shorter support windows for
our upstream components necessitate this reevaluation.

We will be leading discussions on updating our support model, with the
goal of making the model sustainable for the Project.  These
discussions, which will include opportunities for community feedback,
will be complete by March 31, 2019.

Regardless of the outcome of the discussions, we guarantee support for
the stable/12 branch for at least 18 months, or at least 6 months after
13.0 is released, whichever is later.  Again, these are minimum
durations for the stable/12 branch support and they will not be reduced.

After these discussions are complete, there will be a revised statement
about the stable/12 branch lifetime.

Release Engineering, the Security Team, Port Manager, and the Core Team

___
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"

Jailing {open,}ntpd

[Roger Marquis]

Has anyone configured {open,}ntpd to run in a FreeBSD jail or Linux
container?  Can it be done in such a way that a breached daemon would
not have access to the host?

Roger Marquis
___
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"

Re: FreeBSD Security Advisory FreeBSD-SA-18:02.ntp

[Roger Marquis]

Harlan Stenn wrote:

I still think y'all write great security advisories, and I keep aiming
to get our "originals" up to your quality.


High quality work to be sure.  It is still unfortunate that time had to
be wasted on this (and other ntpd advisories).  Much time and insecurity
could have been saved by migrating ntpd to ports and openntpd to base.

One too many cases exactly like this are why OpenBSD and HardenedBSD
forked of course, but it is still not at all clear why openntpd and
other tested and proven security changes haven't been pulled in to
FreeBSD.

Roger Marquis
___
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"

Re: Fwd: [tor-relays] FreeBSD 11.1 ZFS Tor Image

[Roger Marquis]

Shawn Webb wrote:

There's no need for ROP, JOP, SROP, etc. on FreeBSD. FreeBSD is
literally stuck in 1999-era security.


This is doubly true for ports, including Tor.  I submitted a vuxml entry
for apache-tomcat 5 days ago that still has not been committed.  A
follow-up resulted in two replies from a helpful member of the
ports-secteam, but which took as long to write as the vulxml would have
taken to validate and commit.  Its CVE is priority 7 (remotely
exploitable) but almost a week later pkg audit still won't tell you if
you're running an exploitable Tomcat.

The explanation I received is that the ports-secteam is a volunteer
effort and nobody really expects 'pkg audit' to be timely anyhow.

Such easily fixable problems.  Even the FreeBSD Foundation for all the
projects it funds, and could fund with +$2.5M in the bank, doesn't seem
to care.

Roger Marquis
___
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"

Re: Malicious URL ? https://[::]/

[Roger Marquis]

Dag-Erling Sm?rgrav wrote:

Hang on a sec ? localhost should be [::1], not [::], which is the
equivalent of 0.0.0.0.  My guess is a software bug.  Jails look a little
weird from the inside unless you use a fully virtualized network stack.
The proxy probably doesn't have sufficient error checking around
getpeername() or something like that.


Another intermediate URL-checker reports that the plugin in question
(CanvasBlocker) is requesting https://[::]/ directly.  If a bug this is
the first I've seen of it's kind.  If not the question is what threat
profile [::]:443 might expose.  (Other than the obvious jail vector
which really should be fixed.  FreeBSD Foundation where are you?)

Karl's reference to RFC 4291 indicates it is a protocol violation as
well.

The symptom has been reported to Mozilla.

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"

Malicious URL ? https://[::]/

[Roger Marquis]

Not necessarily BSD-related though this was discovered via a proxy
server jail's process table.

Source of the requests was a recently installed Firefox add-on.  Not
sure how to escape the pattern for search engines but nothing is found

From queries wrapped in double quotes.   The absense of previous log

entries or search results raises a number of questions.  Is this
IPv6-related?  Neither the client nor the proxy have IPv6 enabled.  Is
it potentially malicious?  If so by what mechanism?

The Intel IME backdoor vector is a primary suspect for obvious reasons
but am curious if anyone else has seen this?

Roger Marquis
___
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"

Re: http subversion URLs should be discontinued in favor of https URLs

[Roger Marquis]

Karl Denninger wrote:

Advocating the FORCING of https is IMHO utterly ridiculous for the
reasons I pointed out.


This is an important point.  Given the differences of opinion noted here
there is no good reason not to allow sites to sync over the protocol of
their choosing.  Of course signed datasets would be excellent, as would
verifiable builds, but (also IMO) not good enough to justify forcing of
non-encrypted updates.


The issue of potentially-tampered-with source code not only can't be dealt
with correctly through the use of https (at least not with the public CA
infrastructure that "everyone" relies on for "pedestrian" https) there ARE
other means of dealing with it correctly that do not require using https.
That's where attention should be focused.


Would have to disagree with this assertion, at least until it can be
demonstrated that an alternative signature presharing mechanism would be
more secure (than the CA maintained by EFF/LetsEncrypt at least).

IMO,
Roger Marquis
___
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"

New pkg audit FNs

[Roger Marquis]

Can anyone say what mechanisms the ports-security team might have in
place to monitor CVEs and port software versions?

The reason I ask is CVE-2017-12617 was announced almost a week ago yet
there's no mention of it in the vulnerability database  The tomcat8
port's Makefile also still points to the older, vulnerable version.
Tomcat is one of those popular, internet-facing applications that sites
need to check and/or update quickly when CVEs are released and most
admins probably don't expect "pkg audit" to throw false negatives.

Tomcat is just one of many apps, however, so concern regarding the
validity of FreeBSD's vulnerability database is larger than this CVE.
We are concerned about update processes and procedures, especially
considering how this topic has come up in the past (for different apps).

Roger Marquis
___
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"

Re: pkg audit false negatives

[Roger Marquis]

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..


Can you run freebsd-update on a -RELEASE system installed and maintained
with buildworld/buildkernel/installkernel/installworld?

Though it's been more than a year since the last time I tested
freebsd-update, on Virtualbox VMs, it resulted in too many bricked
systems to rely on.  That may have changed but it would still be better
to build a packaged base or have reproduceable builds as lighter-weight
solutions to the base audit issue.

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"

Re: pkg audit false negatives

[Roger Marquis]

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.


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.

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"

Re: pkg audit false negatives

[Roger Marquis]

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.

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
___
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"

Re: pkg audit false negatives

[Roger Marquis]

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.


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.

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"

pkg audit false negatives

[Roger Marquis]

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.

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

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"

Re: fbsd11 & sshv1

[Roger Marquis]

I believe FreeBSD should just have a slave port with OpenSSH 7.4, used only
for SSHv1. People using such port should know the consequences of it.


This could be a good candidate for a new ports category,

  /usr/ports/legacy

If implemented there is a lot of code, in both ports and base, that
should be relocated.  (telnet, rsh/rlogin/rcp/..., nis/yp, rpc.*, cvs,
games, ppp, sendmail, finger, ...)

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"

Re: /tmp/ecp.* created during kernel build?

[Roger Marquis]

Found a couple of ecp binaries in /tmp, apparently created concurrent
with an 11.0 x86_64 kernel build.  Anyone else seen this?  Could they
be related to a "make buildkernel"?


Confirmed 'make buildkernel' does create these files, apparently via
/usr/src/contrib/elftoolchain/elfcopy/main.c (thanks Adam).

Still odd that these are LSB binaries which don't run on this server and
nothing including cleanworld removed them.  Anyone audited elftoolchain
recently?

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"

/tmp/ecp.* created during kernel build?

[Roger Marquis]

Found a couple of ecp binaries in /tmp, apparently created concurrent
with an 11.0 x86_64 kernel build.  Anyone else seen this?  Could they
be related to a "make buildkernel"?

# ls -l /tmp/ecp*
 -rw-r--r--   1 root  wheel  4229 Dec 27 06:21 ecp.Aak1ruL8
 -rw-r--r--   1 root  wheel  2371 Dec 27 06:21 ecp.8Wba0TzO

# file /tmp/ecp.*
 /tmp/ecp.8Wba0TzO: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not 
stripped
 /tmp/ecp.Aak1ruL8: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not 
stripped

# strings /tmp/ecp.Aak1ruL8
 belX
 __vdso_clock_gettime
 __vdso_getcpu
 __vdso_gettimeofday
 __vdso_time
 linux_platform
 linux_rt_sigcode
 linux_vdso.so.1
 LINUX_2.6
 x86_64
 .symtab
 .strtab
 .shstrtab
 .gnu.hash
 .dynsym
 .dynstr
 .gnu.version
 .gnu.version_d
 .eh_frame_hdr
 .eh_frame
 .dynamic
 .data
 .text
 .endrtsigcode
 .getip
 .startrtsigcode
 _DYNAMIC
 _GLOBAL_OFFSET_TABLE_
 clock_gettime
 LINUX_2.6
 __vdso_gettimeofday
 __vdso_getcpu
 gettimeofday
 time
 getcpu
 __vdso_clock_gettime
 linux_platform
 linux_rt_sigcode
 __vdso_time

# strings /tmp/ecp.8Wba0TzO
 linux32_rt_sigcode
 linux32_sigcode
 linux32_vsyscall
 linux_platform
 linux32_vdso.so.1
 LINUX_2.5
 i686
 .shstrtab
 .gnu.hash
 .dynsym
 .dynstr
 .gnu.version
 .gnu.version_d
 .eh_frame_hdr
 .eh_frame
 .dynamic
 .data
 .text

Is there anything else that might trace the origin of these files other
than possibly another buildkernel?

Thanks,
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"

Re: ftpd leaks info which might be useful to an attacker

[Roger Marquis]

Matthew Seaman wrote:

FTP as a protocol is archaic and needs to die.


A good step towards that would be the deprecation of ftpd in base.


As well as the rest of the legacy daemons under /usr/libexec(/*d, other
than tcpd).

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"

Re: ftpd leaks info which might be useful to an attacker

[Roger Marquis]

Matthew Seaman wrote:

FTP as a protocol is archaic and needs to die.


A good step towards that would be the deprecation of ftpd in base.

IMO,
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"

Re: Ports EOL vuxml entry

[Roger Marquis]

Is an outdated (EOL) port a vulnerability? I don't think so. It's a
possible vulnerability, but not a real one.


Exactly.  The meta-discussion we're having is regarding the word 'audit'
(in 'pkg audit').  When you or I audit a server or a site the client
always wants to know about potential vulnerabilities as well as known
ones.  This is because the deliverable is a measure of risk, not just
proven risks but also potential risks.  Even the commercial scanning
tools (Tripwire, Qualis ...) report on potential vulnerabilities as well
as those documented in CVEs.


I have some servers that run legacy code that still needs
python24. Every one of this machines reports right now that there is a
vulnerable package installed and there is no way to tell pkg audit to
stop reporting it.


If my reading of

is correct python24 has documented vulnerabilities.  This is expected of
deprecated software and the reason many of us want to know which
installed packages are deprecated when we run 'pkg audit'.


Sure i can filter python24 from the pkg audit output so it doesn't trigger
the warning.


Why not just 'grep vulnerable' if that's your goal, or 'grep -v
deprecated' (or use a pkg flag to that effect if and when one becomes
available)?


They are a different kind of Security risk and pkg audit should report
them by default as that, but not as vulnerability.


But it's not reporting them as vulnerable, it is reporting them as
deprecated or unmaintained.


There should be a way to state that the sysadmin is aware of the
outdated port and prevent pkg audit from reporting it


Agreed though I expect such a report would see little use.

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"

Re: Ports EOL vuxml entry

[Roger Marquis]

today there was a new entry added to the vuxml file including all
outdated ports. Where is the value in this Entry.


This is good news for many of us Gerhard, who depend on the output of
'pkg audit' for vulnerability information.


In this file should only are real vulnerabilities and not maybe
vulnerable not existing ports.


You raise two issues here, A) what constitutes a 'real' vulnerability
and B) how else would you be warned of probable vulnerabilities (due to
unmaintained and unaudited code).  There is 'pkg version' of course but
few sites use this flag and fewer still use it for vulnerability
information.


Right now this breaks my system to find vulnerable ports on my systems
because all systems with legacy code show up with this entry.


Can you post details of how it breaks your system?


Maybe pkg audit should be print a warning (suppressible by a commandline
switch or a whiltelist in the config file) when discontinued ports are
installed.


A command line switch to ignore deprecated, discontinued and otherwise
unadited ports is an excellent idea though I don't think there will be
much demand for it.  A default 'warn if deprecated' will no doubt be the
modal usage and benefit the larger community (who have until now been
mislead by the output of 'pkg audit').

Thanks for the heads-up.

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"

pkg audit false negatives (was: Perl upgrade - 5.20.x vulnerable)

[Roger Marquis]

On 16 Aug 2016, JosC wrote:

In the absence of running 'pkg audit -F', only
the"LOCALBASE/periodic/security/410.pkg-audit script updates the vuxml
file and audit results. Until that happens, or pkg audit -F is run, pkg
will still see an older version.


Thinking with you I now ask myself:
- Would it be a good idea to make this vuxml file update part of the 
Makefile? Then these occurrences won't happen anymore


There's also an issue with older versions (perl 5.1*) no longer showing
up in the vuln.xml at all.  I've seen perl, php and other critical
network components still in use because the site depended on 'pkg audit'
but did not know that expired OR deprecated ports are not audited.
Apparently this is intentional and by policy.  IMO it is a serious flaw
in pkg audit's design.

A better policy would include expired AND deprecated ports in the output
of 'pkg audit' for at least a year after they are removed from the ports
and/or pkg trees.  If a port had no known vulnerability when removed it
should at least indicate 'no longer audited' in place of 'vulnerable'.

This is, IMO, one of 3 remaining weaknesses in the otherwise excellent
freebsd audit framework.  The other two issues have to do with base not
being packaged (so not really being 'audit'able) and the 'general rule'
announced on Aug 10 that 'the FreeBSD Security Officer does not announce
vulnerabilities for which there is no released patch'.  This is
particularly problematic as there are usually mitigations that do not
require patches.

Roger Marquis
___
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"

Re: freebsd-update and portsnap users still at risk of compromise

[Roger Marquis]

Timely update via Hackernews:

 

Note in particular:

 "FreeBSD is still vulnerable to the portsnap, freebsd-update, bspatch,
 and libarchive vulnerabilities."

Not sure why the portsec team has not commented or published an advisory
(possibly because the freebsd list spam filters are so bad that
subscriptions are being blocked) but from where I sit it seems that
those exposed should consider:

 cd /usr/ports
 svn{lite} co https://svn.FreeBSD.org/ports/head /usr/ports
 make index
 rm -rf /usr/sbin/portsnap /var/db/portsnap/*

I'd also be interested in hearing from hardenedbsd users regarding 
the pros and cons of cutting over to that distribution.


Roger




On 2016-07-29 09:00, Julian Elischer wrote:


not sure if you've been contacted privately, but  I believe the answer is
"we're working on it"


My concerns are as follows:

1. This is already out there, and FreeBSD users haven't been alerted that
they should avoid running freebsd-update/portsnap until the problems are
fixed.

2. There was no mention in the bspatch advisory that running
freebsd-update to "fix" bspatch would expose systems to MITM attackers who
are apparently already in operation.

3. Strangely, the "fix" in the advisory is incomplete and still permits
heap corruption, even though a more complete fix is available. That's
what prompted my post. If FreeBSD learned of the problem from the same
source document we all did, which seems likely given the coincidental
timing of an advisory for a little-known utility a week or two after that
source document appeared, then surely FreeBSD had the complete fix
available.


___
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"

Re: freebsd-update and portsnap users still at risk of compromise

[Roger Marquis]

Question is does this warrant moving from portsnap to svn?

Also have to wonder why the security team hasn't issued a vulnerability
announcement.

Roger





On July 18, John Leyden, security editor at The Register, tweeted a link
to a libarchive ticket that had been sitting without a response for
almost a week.

tweet: https://twitter.com/jleyden/status/755016810865582081
libarchive ticket: https://github.com/libarchive/libarchive/issues/743

The ticket creator quoted an AV researcher who was likely posting to one
of the many early-alert vendor lists in the age of infosec balkanization
(IOW, a "courtesy heads-up" to FreeBSD users forking them money):

[QUOTE]
Our AV researchers have analyzed the following link that was cloud-
submitted as suspect:

https://gist.github.com/anonymous/e48209b03f1dd9625a992717e7b89c4f

The document is from an unknown author and describes "non-cryptanalytic
attacks against FreeBSD update components." The affected components are
the portsnap and freebsd-update tools, both directly and indirectly.

From what we can tell, the text file is part of a larger stash of
documents, all with the same attack-defense style. We have other
documents, dated 2014 and 2015, detailing attacks against the update
systems of multiple Linux distributions and the corresponding defenses
against "the adversary."

We believe this to be the work of an MITM-capable advanced threat actor.

Full details of our findings will be released in the coming weeks. This
is a courtesy heads-up to FreeBSD users.
[/QUOTE]

Another poster confirmed some of the attacks:

[QUOTE]
Here via John Leyden's tweet.

I don't have the time to test the portsnap attacks, but I can confirm
that the libarchive/tar and bspatch attacks work on our 10.x machines,
and I'm happy to test any libarchive/tar fixes.

Judging by the painstaking amount of work put into the bspatch exploit
especially, I think it's highly unlikely that the creator lacks the
means to deploy it via mitm. Otherwise, I've never seen anything like
this in terms of apparent work/reward. It would be comical if it weren't
so horrifying. Think of all those locked-down fbsd machines that have no
external-facing daemons/services and that perform only updates. Our
telecommunications floor alone has several dozen.

Someone needs to alert the fbsd mailing lists (-current, -security?)
pronto. I'd rather not mail them myself from work. And we should also
get more details on the linux distributions.
[/QUOTE]

I've been analyzing the document extensively since then. The targets are
as follows:

[1] portsnap via portsnap vulnerabilities
[2] portsnap via libarchive & tar anti-sandboxing vulnerabilities
[3] portsnap via bspatch vulnerabilities
[4] freebsd-update via bspatch vulnerabilities

Nothing has appeared in any official FreeBSD source about [1]. The
libarchive developers have finally confirmed [2] and are presumably
working on fixes.

A FreeBSD advisory just appeared for [3] & [4] (bspatch), but users
should be aware that running freebsd-update exposes their machines to
the very vulnerability it's correcting (a not insignificant fact that
was omitted from the advisory). Here's why:

[QUOTE]
* The bspatch(1) utility is executed before SHA256 verification in both
* freebsd-update(8) and portsnap(8).
[/QUOTE]

Even worse, the patch in the FreeBSD advisory is insufficient to prevent
heap corruption. I compared the patch in the FreeBSD advisory with the
"defense" patch in the document, and the former contains only a subset
of the checks in the latter. The document patch is in some ways cautious
to an insanely paranoid degree, mistrusting the error-checking stability
of system libraries and defending against compiler quirks that probably
won't exist in compiler optimization intelligence for many years, if
ever, though as a developer of clang-based static analyzers, I did take
an interest in one of the more usual integer-overflow culprits:

...

___
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"

Re: [SECURITY][CORRECTION] CVE-2016-3092 Apache Tomcat Denial of Service

[Roger Marquis]

These vulnerabilities seem to be missing from the current vuln.xml, FYI.

Roger



Date: Wed, 22 Jun 2016 11:02:59 +0100
From: Mark Thomas 
Reply-To: annou...@tomcat.apache.org
To: "us...@tomcat.apache.org" 
Cc: "d...@tomcat.apache.org" ,
   "annou...@tomcat.apache.org" ,
   annou...@apache.org
Subject: [SECURITY][CORRECTION] CVE-2016-3092 Apache Tomcat Denial of Service

Note: This announcement corrects several errors and omissions in the
Tomcat aspects of the announcement for CVE-2016-3092 from the Apache
Commons project that was recently forwarded to various Apache Tomcat
mailing lists.

For the sake of clarity, the Tomcat specific corrections are as follows:
1. This is a Denial of Service vulnerability, not an Information
Disclosure vulnerability.
2. Apache Tomcat 8.5.x is also affected. The vulnerability exists in
8.5.0 to 8.5.2 and affected users of 8.5.x should upgrade to 8.5.3.
3. Apache Tomcat 6.x and earlier are not affected.
4. Applications that do not use the File Upload feature introduced in
Servlet 3.0 are not vulnerable via Tomcat.

A corrected announcement, for Tomcat only, follows.


CVE-2016-3092: Apache Tomcat Denial of Service

Severity: Moderate

Vendor:
The Apache Software Foundation

Versions Affected:
Apache Tomcat 9.0.0.M1 to 9.0.0M6
Apache Tomcat 8.5.0 to 8.5.2
Apache Tomcat 8.0.0.RC1 to 8.0.35
Apache Tomcat 7.0.0 to 7.0.69
Earlier versions are not affected.

Description:
CVE-2016-3092 is a denial of service vulnerability that has been
corrected in the Apache Commons FileUpload component. It occurred when
the length of the multipart boundary was just below the size of the
buffer (4096 bytes) used to read the uploaded file. This caused the file
upload process to take several orders of magnitude longer than if the
boundary length was the typical tens of bytes.

Apache Tomcat uses a package renamed copy of Apache Commons FileUpload
to implement the file upload requirements of the Servlet specification
and was therefore also vulnerable to the denial of service vulnerability.

Applications that do not use the File Upload feature introduced in
Servlet 3.0 are not affected by the Tomcat aspect of this vulnerability.
If those applications use Apache Commons FileUpload, they may still be
affected.

Mitigation:
Users of affected versions should apply one of the following mitigations
- Upgrade to Apache Tomcat 9.0.0.M8 or later
 (9.0.0.M7 has the fix but was not released)
- Upgrade to Apache Tomcat 8.5.3 or later
- Upgrade to Apache Tomcat 8.0.36 or later
- Upgrade to Apache Tomcat 7.0.70 or later

Workaround:
The issue may be mitigated by limiting the length of the boundary.
Applications could do this with a custom Filter to reject requests that
use large boundaries.
Tomcat provides the maxHttpHeaderSize attribute on the Connector that
can be used to limit the total HTTP header size. Users should be aware
that reducing this to 3072 (which should be low enough to protect
against this DoS) may cause other issues as applications can require
larger headers than this for correct operation, particularly if the
application uses relatively large cookie values.

Credit:
This issue was identified by the TERASOLUNA Framework Development Team
at the Software Engineering, Research and Development Headquarters and
reported to the ASF via JPCERT.

References:
http://tomcat.apache.org/security-9.html
http://tomcat.apache.org/security-8.html
http://tomcat.apache.org/security-7.html

___
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"

Re: Batching errata & advisories in heaps degrades security.

[Roger Marquis]

Totally the opposite, it means one rollout instead of X rollouts making it 
simpler not harder.


I don't know, isn't that the logic behind Microsoft's failed
patch-Tuesdays?

It's important not to confound security with usability.  Any delay to a
security advisory is an invitation to hackers.  I don't think that's
what end-users expect from FreeBSD much as the long arm of the NSA might
want to make it so (primarily vis-a-vis CERT and NIST).

Those sites that don't care about security are well served by batching
but given the packaging of base it seems like there's no longer any
significant benefit.

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"

Re: FreeBSD Security Advisory FreeBSD-SA-16:16.ntp

[Roger Marquis]

Large builds over NFS filesystems, particularly secure NFS (i.e.,
Kerberos) are one the best tests of time synchronization.  Clients with
bad clocks can further exercise this not uncommon infrastructure. The
reason you don't typically see build errors even here, IME, is because
the timehosts tend to be shared by and local to both client and server.

Roger



Julian Stacey wrote:

AMD + NFS makes on a LAN. 1/10 second seems insufficient.
( Though one could run a faster less secure NTP on a local LAN
behind a firewall, & a slower more secure NTP on a WAN,
(so a FreeBSD gate would need both NTPs ) ).

___
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"

Re: FreeBSD Security Advisory FreeBSD-SA-16:16.ntp

[Roger Marquis]

Who needs millisecond accuracy anyway?


Cell phones, cell phone towers, computers handling financial transactions, etc.


I manage security for several dozen FreeBSD computers handling financial
transactions and they all run openntpd in client-only mode.  It was the
only way we could avoid an absolute deluge of security incident tickets
from corp scanning (mainly Nessus).

These hosts, as well as cell phone towers, etc may be reasons for
keeping isc ntpd as a port but do not support a case for keeping it in
base.


perhaps, for those sites that need to run ntpd for one of the reasons
listed above but again, that's a tiny fraction of the installed base. Most
FreeBSD systems only need to query a timehost, not to be a time server.


Your data for that?


Are you seriously proposing that most FreeBSD installations need to
serve as timeservers?


openntpd implements SNTPv4 and not the NTPv4 protocol.  The extra sanity 
checking
in the latter helps detect and mitigate against falsetickers, which is why folks
continue to use NTP and ntpd rather than rdate or SNTP implementations like 
openntpd.


And your data for that?  I'd personally be surprised if most devops were
familiar with the differences between SNTPv4 and NTPv4.

OTOH openntpd's ntpd.conf does provide a "constraints from" directive
which will query one or more http/https sites and use the resulting
timestamps to reject ntp responses outside of a range near the
constraint.  This is a nice OOB feature not found in base ntpd.

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"

Re: FreeBSD Security Advisory FreeBSD-SA-16:16.ntp

[Roger Marquis]

Despite the risk of beating a dead horse (apologies to non-native
english speakers for the acronym), as I cannot recall discussion of
migrating base, and since replacing ntpd with openntpd has been standard
practice in security-oriented environments for a few years now, perhaps
someone on the sec team could help me with this question:

What are the reasons FreeBSD has not deprecated ntpd in favor of
openntpd?

Roger



> 2) To update your vulnerable system via a binary patch:
> 
> Systems running a RELEASE version of FreeBSD on the i386 or amd64

> platforms can be updated via the freebsd-update(8) utility:
> 
> # freebsd-update fetch

> # freebsd-update install

___
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"

Re: verify FreeBSD installation

[Roger Marquis]

Hi. Is there any reliable way to verify checksums of all local files for some 
FreeBSD installation? E.g. I'm using a hoster which provides pre-deployed 
FreeBSD instances, how can I be sure there are no any patches\changes in a 
kernel\services etc?


At the filesystem-level there's security/integrit which we use with a
wrapper script for readable reports.  Integrit replaced tripwire when
that company moved away from FOSS.


From the configuration-level there's 'pkg info', 'sysrc -a', 'ipfw sh',

...  and of course the parsed output from /var/log/* to add real-time
monitoring.

I also recommend supplementing these tools with revision tracking for
anything host-specific and non-binary such as /etc/periodic/*/* and
/etc/rc.*.  RCS works well for this on the localhost-level.  On a large
scale ansible is my tool of choice for pulling this information from any
number of hosts into hg or git from which deltas and other reports can be
easily generated.

If you manage a large number of hosts and are interested in helping to
pull all of these tools into a pkg/port let me know.

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"

PVS-Studio Analyzer Spots 40 Bugs In the FreeBSD Kernel

[Roger Marquis]

In light of recently found kernel anomalies[1][2] and considering the
FBI's reckless effort to force Apple to build an iPhone backdoor[3] it
would only be prudent to consider the risk of less transparent efforts by
our three and four letter agencies (and NGOs) targeting our FOSS.
Towards that goal I'm wondering if FreeBSD base has ever been analyzed
for patterns of suspicious commits[4]?

Roger Marquis

Refs.
 [1] http://www.viva64.com/en/b/0377/
 [2] 
http://tech.slashdot.org/story/16/02/19/001202/pvs-studio-analyzer-spots-40-bugs-in-the-freebsd-kernel
 [3] http://www.apple.com/customer-letter/
 [4] 
http://blogs.marketwatch.com/thetell/2014/04/11/heartbleed-bug-was-introduced-seconds-before-new-years-day-2012/
___
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"

Re: [OpenSSL] /etc/ssl/cert.pem not honoured by default

[Roger Marquis]

rhi wrote:

Until now, I have avoided installing the OpenSSL port because the base
OpenSSL gets security updates via freebsd-update and so it's one thing less
to care about... also, I don't like the idea of having two different
versions of the same thing on the system


A fair number of sites have this issue, particularly with ssl and ssh
binaries.  IME this one of FreeBSD's more longstanding administrative and
security weaknesses.  It is paricularly painful for those of us who have
to support a release for several years (after the last base update).


Or is it recommended to let ports use the port OpenSSL, so that base OpenSSL
is only used for the system itself?


If you need the most recent ciphers and protocols you'll normally need to
use the port.  Features are backported from the (higher) port version to
the base version i.e., without bumping the version string, however, it's
not clear whether all applications can take advantage of them.

Matthew Seaman wrote:

There are plans to make many of the base system shlibs private and that
includes switching the ports to use openssl from ports, but I don't think
any changes along those lines are really imminent.


Are you Sure?  3 months ago DES thought they'd be ready for 11:

 > The plan is for 11 to have a fully packaged base system.  There should
 > be some information in developer summit reports on the wiki.  The code
 > is in projects/release-pkg.

However I don't see a projects/release-pkg dir in -CURRENT.

Any recommendations as to how we might help this particular effort?

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"

Re: OpenSSH HPN

[Roger Marquis]

On Wed, 11 Nov 2015, Dag-Erling Sm?rgrav wrote:

I want to keep tcpwrapper support - it is another reason why I still
haven't upgraded OpenSSH, but to the best of my knowledge, it is far
less intrusive than HPN.


There's also inetd's tcpwrapper support if you call sshd from inetd for
D/DOS protection.  Inetd and its rate-limiting flags are strongly
recommended for security-minded systems.

Starting sshd from rc.d should never have been made the default, IMO, as
keygen delays are rarely relevant and weren't even back in the days of
300MHz CPUs (18 years ago).  The only reason inetd is not more widely
used today is that many sysadmins aren't familiar with it.

Roger Marquis
___
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"

vuln.xml to oval script?

[Roger Marquis]

Anyone familiar with the OS repositories for OVAL
<http://oval.mitre.org/repository/>?  Considering how similar these dbs are to
vuln.xml it seems odd that FreeBSD is not represented as a "supported
operating system".

If any XML devs are reading this, how difficult would it be to write a
translation script?

Roger Marquis

___
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"

Re: HTTPS on freebsd.org, git, reproducible builds

[Roger Marquis]

Glen Barber wrote:

In fact, Debian has been kind enough to even provide a page that shows
which parts of the FreeBSD build are non-reproducible.

https://reproducible.debian.net/freebsd/freebsd.html


This issue is one of the reasons secure sites do not use binary packages
or freebsd-update.  It also illustrates problems admins have when
required to buildworld/installworld when all they should need to do is
"cd /usr/src/crypro/openssh& install" (for example).  Does anyone
have a link to the archived discussion detailing why this functionality
was deprecated?

These are good and timely subjects given recently published details of
NSA/5 eyes methodologies as well as the issues freebsd security teams
were having as recently as a few months ago.

Roger Marquis

Refs.
  
https://igurublog.wordpress.com/2014/04/08/julian-assange-debian-is-owned-by-the-nsa/
  http://www.linuxjournal.com/content/debian-project-aims-keep-cia-our-computers
  http://www.tedunangst.com/flak/post/reproducible-builds-are-a-waste-of-time
___
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"

Re: avoiding base openssl when building ports

[Roger Marquis]

Kimmo Paasiala:

Rumour is that something like that is going to happen with all of the
problematic libraries by making them private. If someone with inside
knowledge could confirm these rumours? ;)


Curious why this is a rumor?  Open source operating systems should be
developed transparently, shouldn't they?


This leads to another question. Where is the line going to be drawn
which libraries in the base system should be private? There are
certainly some of them that have to be public like libc and the
support libraries like libusb. There is certainly no sense in making
the ports system use full set of its own libraries for everything
either.


I'd be happy just to to 'make buildworld -DWITHOUT_OPENSSL'.

Roger Marquis
___
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: New pkg audit / vuln.xml failures (php55, unzoo)

[Roger Marquis]

Walter Parker wrote:
 What actual assurance do Debian, Ubuntu, Redhat, and Suse provide that
 their systems are secure? An audit trail of CVE issues fixed, while a
 good start. is hardly a strong assurance that the system is secure.

An important point and thank you for making it Walter.  There is no assurance
against zero-day vulnerabilities or vulns that are otherwise not published
(outside of the NSA).  That would be absolute security.  In the context of
relative security, however, assurance can perhaps be defined as being able to
assume that CVEs released by the NIST, announced by code or other operating
system  maintainers or published by researchers or third parties such as
Rapid7 and Tripwire are reflected in vuln.xml (after a reasonable timeframe).

 How much faster must FreeBSD respond for it to join the security
 assurance club of the major Linux vendors? Is this a paperwork issue
 or a process issue?

We don't have much insight into the workings of FreeBSD's security teams so it
appears to be a matter of policy.  Would be great if Dag could comment here. 
The policies I would most like to know about are transparency-related i.e.,
published security-related procedures, projects and RFCs.  Otherwise, what
appears to be lacking is (additional) automation of the process of scanning
CVEs and advisories by other organizations and subsequent prioritization,
review and formatting for publication.

There are several of us interested in contributing towards these goals,
financially, codewise and otherwise, but it is distressingly unclear how. 
There are PRs of course, but if, say, someone wanted to contribute
specifically to the process of automating vuln.xml updates or to donate
specifically to the security teams    Pointers gladly accepted.

Roger

___
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: New pkg audit / vuln.xml failures (php55, unzoo)

[Roger Marquis]

   * operators of FreeBSD servers (unlike Debian, Ubuntu, RedHat, Suse and
   OpenBSD server operators) have no assurance that their systems are
   secure.

 Slow down here for a second. Where's the command-line tool on RedHat or
 Debian that lists only the known vulnerable packages?

In RedHat you can create a security repo list (
grep -security /etc/apt/sources.list), install the security plugin (yum
install yum-plugin-security) and 'yum check-update --security' for the same
functionality as 'pkg audit -F'.  Debian is even more obscure (apt-get upgrade
-o Dir::Etc::SourceList=/etc/apt/security.sources.list --just-print).  FreeBSD
'pkg audit' is much cleaner but what difference does that make, really, when
you have a vulnerable package that isn't in the database?

 But that's not the end of the story. That
 command won't list vulnerabilities until they have a patch released.
 Let's look at CVE-2015-0209
 https://access.redhat.com/security/cve/CVE-2015-0209
 Release date was March 23rd.

No question there's variability in bugfix timeliness, especially for DOS-type
bugs like CVE-2015-0209.  FreeBSD ports maintainers are also able to commit
patches and version updates much more quickly than their binary-only
competitors, as noted with the php55/Makefile tweak.  In the past that's what
made FreeBSD a more secure OS to host applications on.  But that's not the
main issue this thread has been about.

The issue that really matters from a security perspective is the completeness
of the vulnerability database, vuln.xml in our case.

 The grass is always greener... or is it?

 Let's just concentrate on how to improve things here and not worry about
 how they're handling security issues because they have their own unique
 problems to solve.

I must say I am disappointed in the response to this serious and significant
issue.  My Redhat using co-workers, OTOH, are no doubt eating it up.  Problem
is I'm not the only one who has to defend their business unit's use of FreeBSD
in a corporation that has otherwise nearly standardized on Redhat (and RH
security, bash notwithstanding).

Roger


___
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: New pkg audit / vuln.xml failures (php55, unzoo)

[Roger Marquis]

 Mark Felder wrote:
 Who is ports-secteam?

 It was Xin Li who alerted me to the ports-sect...@freebsd.org address
 i.e., as being distinct from the FreeBSD Security Team
 (sect...@freebsd.org) address noted on
 https://www.freebsd.org/security/.

Also have to thank Remko Lodder for pointing out the ports-secteam@ address.
Should also note that while the ports-secteam@ is not mentioned in
freebsd.org/security or various other places where it probably should be
(like the Types of Problem Reports page
/doc/en_US.ISO8859-1/articles/pr-guidelines/pr-types.html)
it is noted in the Port Specific FAQ /doc/
en_US.ISO8859-1/articles/pr-guidelines/pr-types.html and on the port
mainters' page /ports/ports-mgmt.html.

Roger


 There has been no Call For Help that I've ever seen. If people are needed
 to process these CVEs so they are entered into VUXML, sign me up to
 ports-secteam please.

 I believe that is part of the problem, or the multiple problems, that
 lead me to believe that FreeBSD is operating without the active
 involvement of a security officer.  Specifically:

   * port vulnerability alerts sent to secteam@, as indicated on the
   /security/ page, are neither forwarded to ports-secteam@ for review nor
   returned to the sender with a note regarding the correct destination
   address,

   * the freebsd.org/security web page is not correct and not being
   updated,

   * aside from Xin nobody from either ports-secteam@ or secteam@ much
   less security-officer@ seems to be reading or participating in the
   security@ mailing list,

   * nobody @freebsd.org appears to be following CVE announcements and the
   maintainers of several high profile ports are also not following it or
   even their application's -announce list,

   * there appears to be no automated process to alert vuln.xml maintainers
   (ports-secteam@) of potential new port vulnerabilities,

   * offers of help to secteam@ and ports-secteam@ are neither replied to
   nor acted upon (except for Xin Li's request, thanks Xin!),

   * perhaps as a result the vuln.xml database is no longer reliable, and
   by extension,

   * operators of FreeBSD servers (unlike Debian, Ubuntu, RedHat, Suse and
   OpenBSD server operators) have no assurance that their systems are secure.

 This is a MAJOR CHANGE from just a couple of years ago which calls for an
 equally major heads-up to be sent to those running FreeBSD servers and
 looking to the freebsd.org website for help securing their systems.

 The signifiance of these 7 bullets should not be overlooked or
 understated.  They call in to question the viability of FreeBSD itself.

 IMO,
 Roger Marquis



___
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

New pkg audit / vuln.xml failures (php55, unzoo)

[Roger Marquis]

FYI regarding these new and significant failures of FreeBSD security
policy and procedures.

PHP55 vulnerabilities announced over a week ago
https://www.dotdeb.org/2015/05/22/php-5-5-25-for-wheezy/) have still
not been ported to lang/php55.  You can, however, edit the Makefile,
increment the PORTVERSION from 5.5.24 to 5.5.25, and 'make makesum
deinstall reinstall clean' to secure a server without waiting for the
port to be updated.  Older versions of PHP may also have unpatched
vulnerabilities that are not noted in the vuln.xml database.

New CVEs for unzoo (and likely zoo as well) have not yet shown up in 'pkg
audit -F' or vuln.xml.  Run 'pkg remove unzoo zoo' at your earliest
convenience if you have these installed.

  HEADS-UP: anyone maintaining public-facing FreeBSD servers who is
  depending on 'pkg audit' to report whether a server is secure it should
  be noted that this method is no longer reliable.

If you find a vulnerability such as a new CVE or mailing list
announcement please send it to the port maintainer and
ports-sect...@freebsd.org as quickly as possible.  They are whoefully
understaffed and need our help.  Though freebsd.org indicates that
security alerts should be sent to sect...@freebsd.org this is
incorrect.  If the vulnerability is in a port or package send an alert to
ports-secteam@ and NOT secteam@ as the secteam will generally not reply
to your email or forward the alerts to ports-secteam.

Roger


Does anyone know what's going on with vuln.xml updates?  Over the last
few weeks and months CVEs and application mailing lists have announced
vulnerabilities for several ports that in some cases only showed up in
vuln.xml after several days and in other cases are still not listed
(despite email to the security team).

___
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: pkg audit / vuln.xml failures

[Roger Marquis]

ports-secteam@ owns this file, not secteam@.


Thanks for the pointer Bryan.  I would hope that port vulnerability
emails are forwarded from secteam@ to ports-secteam@, by policy, as the
freebsd.org website is not clear on this.  Either way at least I/we now
know the right address/es.


The team needs more help.
Would you like to volunteer to submit vuxml updates? Many contributors,
and committers, feel the file is not easy to contribute to.


I have been submitting ports vulnerability updates and will continue to
do so (now to ports-secteam@).  If there are any open seats on
ports-secteam I would like to contribute on that level as well.

Still interested in the team's policies and procedures, if those are
online somewhere.

Roger Marquis
___
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: Forums.FreeBSD.org - SSL Issue?

[Roger Marquis]

You're not understanding the situation: the vulnerability isn't in
OpenSSL; it's a design flaw / weakness in the protocol. This is why
everyone is running like mad from SSL 3.0 and TLS 1.0.


Right, there are two issues being discussed that should be separated.
The thread was originally about SSL version weaknesses and the rational
for that (keeping v1.0 around for the near term) was described quite
well.

The second issue was regarding base and ports versions of openssl and how
to coordinate between them.  I recommended an openssl_base port so that
security vulnerabilities (not necessarily protocol weaknesses) could be
more easily remediated (than installworld) and so 'pkg audit' could
report on those.  It was asserted and reasserted that this would be
infeasible, however, no example or reason was given.  Considering the
time to write and test patches is the same in either case it is still an
open question.

The problem of multiple versions of the same libraries and binaries,
however, remains a weakness in the FreeBSD security model.  This may be
one of the reasons why the EU recently recommended more widespread
adoption of OpenBSD (vs FreeBSD).  Either way, it is a design flaw that
can and should be solved in the most robust way possible.

Roger
___
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: Forums.FreeBSD.org - SSL Issue?

[Roger Marquis]

Mark Felder wrote:

In the future FreeBSD's base libraries like OpenSSL hopefully will be
private: only the base system knows they exist; no other software will
see them. This will mean that every port/package you install requiring
OpenSSL will *always* use OpenSSL from ports/packages; no conflict is
possible.


That's one way of approaching it but there are drawbacks to this method.
Maintaining two sets of binaries and libraries that must be kept separate
(using what kind of ACLs?) adds complexity.  Complexity is the enemy of
security.

Another option is a second openssl port, one that overwrites base and
guarantees compatibility with RELEASE.  Then we could at least have all
versions of openssl in vuln.xml (not that that's been a reliable
indicator of security of late).

Roger Marquis
___
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: Forums.FreeBSD.org - SSL Issue?

[Roger Marquis]

Mark Felder wrote:

Another option is a second openssl port, one that overwrites base and
guarantees compatibility with RELEASE.  Then we could at least have all
versions of openssl in vuln.xml (not that that's been a reliable
indicator of security of late).



This will never work. You can't guarantee compatibility with RELEASE and
upgrade it too.


How do you figure?  RedHat does exactly that with every backport, and
they do it for the life of a release.

Roger
___
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

Enumerating glibc dependencies

[Roger Marquis]

Before pkgng it was easy to list a system's port dependencies by
(starting with):

  grep glib /var/db/pkg/*/*

Is there an equivalent (single) command for pkgng?

Roger
___
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: Enumerating glibc dependencies

[Roger Marquis]

Please note that the glibc has nothing to do with glib.


Is FreeBSD glib always linked to libc (vs glibc)?

 # ldd /usr/local/lib/libglib* 2/dev/null| grep libc | sort -u
 libc.so.7 = /lib/libc.so.7 (0x800648000)

Roger
___
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: Enumerating glibc dependencies

[Roger Marquis]

Is FreeBSD glib always linked to libc (vs glibc)?


Apparently it is, at least on the systems I've tested where there were no
glibc dependencies at all.  Another item added to the list of BSD
(security) advantages.

Roger
___
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:02.kmem

[Roger Marquis]

  If SCTP is NOT compiled in the kernel, are you still vulnerable ?
 
  No -- we should have mentioned that too.  For GENERIC kernel however
  SCTP is compiled in.

 Should probably fix that too, in GENERIC, considering how little used this
 protocol is.

 It is not used much because there is not critical mass and you want
 to reduce what little there is out there?  It is a good thing that
 it is in GENERIC.

While this isn't the place to enumerate the issues with SCTP (beyond the
recent advisories) I hope we're not putting anything in the GENERIC kernel for
advocacy purposes.  Cannot the few who want to use it simply compile their own
kernel?

Roger

___
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-14:31.ntp

[Roger Marquis]

 DES wrote:
 I do it all the time:
 $ sudo env UNAME_r=X.Y-RELEASE freebsd-update fetch install

Not sure if using a jail to test is relevant but this never updates (my)
binaries to the specified RELEASE/RELENG, only to the current kernel's patch
level.

Then there's the issue of specifying -RELEASE to mean -RELENG.

 Not sure what you mean by scope issues.

That's referring back to the original question of buildworld/installworld vs
cd /usr/src/path/to/patched/binary;make install (vs freebsd-update) and the
granularity of respective updates.

 Actually, you want to do this from *outside* the jail, partly out of
 healthy paranoia and partly so freebsd-update will re-use previously
 downloaded indexes and patches

Updates to non-jailed environments are the preferred method to be sure but
patching and testing base updates in a jail can be more convenient.

Roger

___
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-14:31.ntp

[Roger Marquis]

Dag-Erling Sm?rgrav wrote:

Roger Marquis marq...@roble.com writes:

... or those with constrained resources are never going to be able
to make/build/installworld for something as simple as a single binary
update.


These sites would be better served using freebsd-update to download and
apply binary patches.


Was afraid you might say that, not because it's unreasonable or
inevitable but because it illustrates the increasing tendency to refer
bug (and other) reports to use binary updates.

Problem with freebsd-update is that it has some of the same scope issues
as installworld.  We've also had problems defining -r (in a jail) when
the booted kernel is not the revision we want to build to.  Doesn't help
that -r doesn't parse patch levels.

freebsd-update also calls phttpget which has no man page.  This is one
Linux-ism (missing man pages) that FreeBSD is usually good at avoiding.


I would suggest discussing this with the FreeBSD Foundation.  They have
already taken an interest in the matter.


Thanks Dag,
Roger
___
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-14:31.ntp

[Roger Marquis]

Dag-Erling Sm?rgrav wrote:


Eugene Grosbein wrote:

Why does it say Recompile the operating system using buildworld and
installworld?


Because that's what the template says, and we rarely change it to
something more specific (in large part because that requires careful
testing of the exact instructions we publish).  Rebuild, reinstall and
reboot may be overkill, but it's never wrong.


This is most unfortunate as it creates a high bar for base security
patches at many FreeBSD shops.  Sites with a significant number of
production hosts, jails and/or filesystem fingerprinting (integrit,
tripwire) or those with constrained resources are never going to be able
to make/build/installworld for something as simple as a single binary
update.

I assume the root cause is insufficient resources within the freebsd
security team.  If that's the case would there be a budget estimate
associated with addressing this security advicory situation?  Since quick
publication of advisories is critical this also raises the question of
what might be an effective way to subsequently publish more granular
update instructions.

Roger Marquis
___
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: ntpd vulnerabilities

[Roger Marquis]

Dag-Erling Sm??rgrav wrote:

I absolutely agree.  If we replace the NTP suite, it will be with a
minimal SNTP client, although no decision has been made.


For now openntpd is the recommended solution but a more minimal client
might be preferable depending on implementation specifics.  The only
feature missing from openntpd that we could use is a way to set the
egress interface.  Openntpd's listen on directive only defines the
ingress tcp adddress, outgoing queries still use the server's primary ip.

Roger Marquis
___
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: getting the running patch level

[Roger Marquis]

Jilles Tjoelker wrote:

I think the idea of having 'make installworld' create something is good,
but we should not hard-code policy by writing the information into a
file that may be shown to unauthenticated users (such as by getty).

A new file with a name=value format somewhat like /etc/lsb-release on
Linux seems more appropriate. If the admin wants /etc/issue,
/etc/rc.d/motd can create it.


Automatically updating /etc/issue (or /etc/issue.net, but not issue.*
should that be adopted from other OS) has security implications due to
potentially unintended information disclosure.

WRT writing a new file, something like /etc/bsd-release would be a good
choice following the principle of least surprise.  Mergemaster can and
should ignore it (and motd, issue, ...).

Strict adherence to the KIS principle, however, would only write this
information to the first line of the motd, after the kernel info.

Simon Nielsen wrote:

A simple approach would be to just append -uX to the uname string, but I'm
not really sure if I like that... To ilustrate, if for a 9.0 system, where
kernel is patch 3 userland is patch 5, we would show FreeBSD
9.0-RELEASE-p3-u5. The nice thing is that we don't try to be clever and
therefor are less likely to get it wrong.


There's not a good way to report on every userland (lib/binary) file but
a simple find and/or checksum (a la integrit) could indicate whether
anything had been updated since the last installworld.  That could be
noted by appending a simple -modified to whatever uname prints for the
userland version.  Attempting to do more than that, IMO, would have a
negative ROI.

IMO,
Roger Marquis
___
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: periodic security run output gives false positives after 1 year

[Roger Marquis]

The correct format is 2012-02-20T01:23:45.6789+01:00


You guys are aware that RFC 5424 is a proposed standard I trust?  By
being proposed it is not a standard, at least not yet.

Perhaps the differences in human-readability of the proposed timestamp,
or the fact that it has variable field types and lengths, are part of the
reason why it has not been ratified.

Other parts of this particular RFC bring its trustworthiness into
question.  In particular the quote Research during creation of this
document showed that there is very little in common between different
syslog implementations on different platforms. with no detail on the
so-called research methodology.  In my own experience syslog timestamps
are identical across FreeBSD, CentOS, Debian, Ubuntu and Solaris, which
represent well over 99% of the installed base.

Regarding backwards compatibility, I'd be interested in knowing how many
systems, how many logs and how many log-parsing applications those
proposing change are responsible for?  Would not be surprised if, like
others proposing deprecating long-used Unix standards, those advocating
the change are not the ones whose workloads or budgets would be impacted.

Roger
___
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: periodic security run output gives false positives after 1 year

[Roger Marquis]

Sergey Kandaurov wrote:

In IETF this RFC is marked obsolete and replaced with RFC 5424 with
different timestamp format in ISO 8601 form. FreeBSD doesn't implement
5424 yet. Almost complete implementation was done in NetBSD in that
regard in 2008. NetBSD before RFC 5424 changes has had pretty similar
syslogd source, so if one could analyze and port that changes to FreeBSD,
that would be pretty nice.


Problem with that would be backwards compatibility, and it's not IMO
worth breaking everyone's syslog parsing scripts to fix an issue that
really isn't due to the date format as much as it is to log rotation.

That's not to say that security scripts don't need to parse archived
logs, just that they should perhaps check the date stamp of the archive
files before parsing.

Have to admit we don't use FreeBSD (or any other OS's) log rotation or
log-related periodic scripts.  Would love to submit replacements though.
Our logic is a bit different:

 * rotating current log files, to /var/log/$log.$i only when they grow
   larger than 100MB,

 * checking log file size hourly,

 * rotating all logs regardless of size only at the end of the month, to
   a compressed file with the date stamp as part of the filename,

 * maintaining monthly archived log files in a dedicated subdirectory
   (/var/log/logarchive),

 * writing each syslog facility to its own file (kern.log, local1.log,
   ...).

It is unfortunate that syslog is such a neglected and unoptimized aspect
of nearly all Unix and Linux default installs but SA's don't have to
restrict their systems to those defaults.

Roger Marquis
___
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: periodic security run output gives false positives after 1 year

[Roger Marquis]

1) Make it an option.
2) If it isn't set, keep the output like it is now.
3) Set it by default in new installs, with a comment above it that it
might break things. That way people upgrading get a warning, too, and
can keep it the way it has been if they'd like.


You can, but it'd be like sendmail logging which has no fixed format and
correspondingly few log report programs.  OTOH Postfix learned from that
and made its log format immutable.  As a result there are some nice
syslog-reading report utilities for postfix.

POSIX' Austin group tried to do something similar by proposing a
LOCALE-dependent month field of variable length instead of 3 char English
month names.  Not aware of anyone who used that.  It was never a good
idea but the Austin group is small, has alarmingly little concern for
backwards compatibility, and does not solicit end-user input.  FreeBSD is
still my favorite OS in large part because it is not like POSIX' Austin
group in those respects.

Roger Marquis

___
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

[Roger Marquis]

Elmar Stellnberger wrote:

 I believe it would be highly desireable to have an online md5sum
verification for FreeBSD as this is already implemented by checkroot


This is not difficult to do on a per-host basis using integrit, cron and
optionally md5 with mail, ftp or scp.


(http://www.elstel.com/checkroot/) for openSUSE. This is often the only
way to spot an intrusion.


Unlike SuSE and Solaris, FreeBSD is most often compiled on the local
host.   Wouldn't that make global checksums relatively useless?

Roger Marquis

___
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

DNS probe sources

[Roger Marquis]

These source addresses are likely spoofed, but am still curious whether
other FreeBSD admins saw a preponderance of DNS probes originating from
Microsoft corp subnets ahead of the recent ISC bind vulnerability
announcement?

Roger Marquis


 Jul 28 16:51:23 PDT named[...]: client 94.245.67.253#10546: query (cache) 
'output.txt/A/IN' denied
 Jul 28 16:51:23 PDT named[...]: client 94.245.67.253#10543: query (cache) 
'output.txt/A/IN' denied
 Jul 28 16:51:18 PDT named[...]: client 94.245.67.253#10546: query (cache) 
'output.txt/A/IN' denied
 Jul 28 16:51:18 PDT named[...]: client 94.245.67.253#10543: query (cache) 
'output.txt/A/IN' denied
 Jul 28 16:51:13 PDT named[...]: client 94.245.67.253#10546: query (cache) 
'output.txt/A/IN' denied
 Jul 28 16:51:13 PDT named[...]: client 94.245.67.253#10543: query (cache) 
'output.txt/A/IN' denied
 Jul 28 16:51:08 PDT named[...]: client 94.245.67.253#10370: query (cache) 
'/A/IN' denied
 Jul 28 16:51:08 PDT named[...]: client 94.245.67.253#10366: query (cache) 
'/A/IN' denied
 Jul 28 16:51:03 PDT named[...]: client 94.245.67.253#10370: query (cache) 
'/A/IN' denied
 Jul 28 16:51:03 PDT named[...]: client 94.245.67.253#10366: query (cache) 
'/A/IN' denied
 Jul 28 16:50:58 PDT named[...]: client 94.245.67.253#10370: query (cache) 
'/A/IN' denied
 Jul 28 16:50:58 PDT named[...]: client 94.245.67.253#10366: query (cache) 
'/A/IN' denied
 Jul 28 07:25:45 PDT named[...]: client 207.46.57.240#37973: query (cache) 
'output.txt/A/IN' denied
 Jul 28 07:25:45 PDT named[...]: client 207.46.57.240#37959: query (cache) 
'/A/IN' denied
 ...
 Jul 27 23:24:47 PDT named[...]: client 94.245.67.253#55561: query (cache) 
'output.txt/A/IN' denied
 Jul 27 23:24:32 PDT named[...]: client 94.245.67.253#55354: query (cache) 
'/A/IN' denied
 Jul 27 15:10:33 PDT named[...]: client 207.46.57.240#17255: query (cache) 
'output.txt/A/IN' denied
 Jul 27 15:10:33 PDT named[...]: client 207.46.57.240#17242: query (cache) 
'/A/IN' denied
 ...
 Jul 24 07:21:22 PDT named[...]: client 94.245.67.253#15828: query (cache) 
'output.txt/A/IN' denied
 Jul 24 07:21:07 PDT named[...]: client 94.245.67.253#15637: query (cache) 
'/A/IN' denied
 Jul 24 06:10:30 PDT named[...]: client 207.46.57.240#59717: query (cache) 
'output.txt/A/IN' denied
 Jul 24 06:10:30 PDT named[...]: client 207.46.57.240#59707: query (cache) 
'/A/IN' denied
 ...
___
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: ports/128749: [vuxml] VBA parser vulnerability in ClamAV

[Roger Marquis]

As was recently reported in the BugTraq list, VBA parser in ClamAV is
contains the off-by-one overflow and can lead to the arbitrary code
execution within the clamd process.

VBA component seem to be unconditionally included to the libclamav
and OLE2 scanning is on by-default.


FWIW, clamav-0.94.1 does not compile under 5.X without CONFIGURE_ARGS+=
--disable-gethostbyname_r.  When compiled this way it does not run (exits
after initialization with no error logging).

Though 5.X is no longer officially supported there are many sites still
running it which could benefit from a patch, assuming it would be trivial
to create such a patch.

Roger Marquis
___
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?

[Roger Marquis]

Jason Stone wrote:

I don't agree with the criticism of the security team; it takes a lot of
time to test things and make sure that changes and patches work within the
larger context of a complete system.


There's that, but you also have to consider ISC's role.  They certainly put
a lot into testing named on all the common platforms.  I'm pretty sure
FreeBSD is still one of their test platforms.  Not so sure it will continue
to be though, given the resources our polished OS seems to be limited to.


And what I like about FreeBSD is that it's a complete system,
not just a collection of disjoint parts like some other popular
unix-like systems out there


Don't know if I agree given the way dozens of port versions were
unnecessarily incremented recently.
http://unix.derkeiler.com/Newsgroups/comp.unix.bsd.freebsd.misc/2008-06/msg00231.html

At least we _can_ easily update bind ports, I mean without waiting for
maintainers or QA.
http://unix.derkeiler.com/Newsgroups/comp.unix.bsd.freebsd.misc/2008-07/msg00058.html

But the real issue here is FreeBSD's response in comparison with other
Unix/Linux operating systems.  This is a critical time for FreeBSD.  If we
can't keep up, response-time-wise, patch-wise, finance-wise, or otherwise,
our OS won't last long.  The competition has gotten too good.

Question is, OT but very relevant, how can FreeBSD get some decent corporate
sponsorship?

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

Re: openssldoesn't -overwrite-base again (was: FreeBSD-SA-08:05.openssh)

[Roger Marquis]

Dirk Meyer wrote:

The -overwrite-base option was only functional on FreeBSD 4.x
With FreeBSD 5.x the libs are spread in /lib and /usr/lib, so
even if the ports overwrite base libs, some tools still use the
old (unpatched) libs from /lib.


Couldn't this be addressed simply by removing the old libs,
possibly replacing with symlinks, in coordination with the
standard/base?

We shouldn't need to worry about base applications linked to the
old libs anyhow, unless a base app is making unreasonable
expectations. Better to fix those bugs in base, IMO, than have
multiple versions of key libraries.

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

openssldoesn't -overwrite-base again (was: FreeBSD-SA-08:05.openssh)

[Roger Marquis]

I'd like to thank the openssh-portable port maintainer/s for
preserving the -overwrite-base option. This eases our systems and
security update jobs measurably.

Unfortunately, openSSL has dropped the -overwrite-base option
(again), leaving us with two versions of openssl and some
confusion over A) which version of openssl a new port or upgrade
(i.e., openssh) will use, and B) how to update systems with
openssl-overwrite-base installed.

Is there a best practice/recommendation for updating
openssl-overwrite-base without having to maintain multiple
versions?

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

Re: I cannot upgrade openssl-stablr

[Roger Marquis]

Dirk Meyer wrote:

Try adding OPENSSL_OVERWRITE_BASE=yes into your /etc/make.conf
file, and try again. You can also define that variable at build
time, but having it in make.conf keeps it there for future
reference.


OPENSSL_OVERWRITE_BASE=yes sould be used with extreme caution!


I disagree, never having had a problem with OPENSSL_OVERWRITE_BASE.


This might break your base application in cases like this, when
the base uses a diffrent api as the ports does.


That would be a version mis-match, not really related to overwriting
the base port. Indeed if you install openssl without
OPENSSL_OVERWRITE_BASE you will have two different versions on your
your system, which is much more of a sysadmin headache than an easily
diagnosed version mismatch. For the same reason I recommend
OPENSSH_OVERWRITE_BASE, NO_MAILWRAPPER, NO_SENDMAIL, NO_OPENSSH,
NO_OPENSSL, NO_BIND, and PORT_REPLACES_BASE_BIND8 or
PORT_REPLACES_BASE_BIND9 as well.

OPENSSL_OVERWRITE_BASE should be the default, but consider adding
WITH_OPENSSL_097 to prevent automatic incompatible version upgrades.
Most of the sites I consult with have stuck with the 0.9.7 branch for
compatibility reasons.

Is it still the case that 'make *world' cannot parse
OPENSSL_OVERWRITE_BASE and requires NO_OPENSSL instead?

--
Roger Marquis
Roble Systems Consulting
http://www.roble.com/
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: FreeBSD Security Survey

[Roger Marquis]

Peter Jeremy wrote:

One of the major problems with unattended/automatic updating is
that it is hard to filter them.


It's hard to make a good case for automatic updates when manual
updates are so easy. The main area this could be improved on would
be in a daily report, emailed to root, detailing which installed
ports are out of date. We do this with a shell script
http://www.roble.com/docs/cvsup-ports-rep.

One issue with identifying out-of-date installed ports is the
port-version number. We usually ignore port-version-only updates
because it's difficult to tell what was changed and few changes
aren't detailed in /usr/ports/UPDATING.

Another issue has to do with policy regarding -release, -rc, -alpha
versioning. Too many ports maintainers think nothing of using
-pre-release versions that are usually not appropriate on -release
systems.

All that said FreeBSD's ports are still the reference
implementation, head-and-shoulders better than up2date, yum, rpm,
apt-get, or anything else out there.

--
Roger Marquis
Roble Systems Consulting
http://www.roble.com/
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Need urgent help regarding security

[Roger Marquis]

Lowell Gilbert wrote:

Not sure I agree with the easily part..  TCP transport plus SSH
protocol spoofing is not a vector that normally needs to be secured
beyond what is already done in the kernel and router.  That's not to
say such spoofing cannot be done, just that it is rare and would
require a compromised router or localnet host at a minimum.


Except that it doesn't require spoofed addresses.  One attacker from the
local university's computer center (or from a large shell service ISP)
could lock out all of the other users on that machine.  Trivially.


And that's exactly what you want.  The alternative is to let the
dictionary attack continue unabated.

At least once the blackhole is up, and notices sent, the target
host's admins can contact the attacking host's admins to shutdown
the account or process running the scan.

If nobody is monitoring the IDS alerts that's a different problem.

--
Roger Marquis
Roble Systems Consulting
http://www.roble.com/
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Need urgent help regarding security

[Roger Marquis]

 2) running an sshd IDS that A) tests for '(for invalid user|Failed
 password for)', B) blacholes source hosts 'ipfw add deny ...', and
 C) alerts sysadmin or operations personnel,


Be careful with adding ip addresses to deny via a packet filter.
If an attacker uses spoofed IP adresses, you may produce yourself
easily a denial of service attack.


Not sure I agree with the easily part.  TCP transport plus SSH
protocol spoofing is not a vector that normally needs to be secured
beyond what is already done in the kernel and router.  That's not to
say such spoofing cannot be done, just that it is rare and would
require a compromised router or localnet host at a minimum.

Say I used the IP address of your default gateway. If you 
don't check that and just add a deny rule... well... bad luck ;-)


I would hope that your router doesn't accept packets with its own
source address.  But this does bring up a good point i.e, that no
IDS should be operated without a well thought-out whitelist.

--
Roger Marquis
Roble Systems Consulting
http://www.roble.com/
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]