Re: Possible break-in attempt?

[Jamie Landeg-Jones]

Dimitry Andric  wrote:

> For each incoming IP address, sshd does a reverse lookup, and if that
> results in a hostname, it does another lookup of that hostname, to see
> if *that* result matches the original incoming IP address.  If it does
> not, you get this scary warning in syslog about a "possible break-in
> attempt!".
>
> In my opinion, this is fairly misleading, since almost always the actual
> cause is badly configured DNS, a very common occurrence.  In addition,
> matching forward and reverse DNS records is no guarantee at all that the
> incoming IP address is in any way trustworthy.

I'm not sure which version this made it into, but they actually removed this
over 2 years ago. It's not in the openssh that ships with FreeBSD 11.2:

 | commit e690fe85750e93fca1fb7c7c8587d4130a4f7aba
 | Author: dtuc...@openbsd.org 
 | Date:   Wed Jun 15 00:40:40 2016 +
 |
 | upstream commit
 |
 | Remove "POSSIBLE BREAK-IN ATTEMPT!" from log message
 | about forward and reverse DNS not matching.  We haven't supported 
IP-based
 | auth methods for a very long time so it's now misleading.  part of 
bz#2585,
 | ok markus@
 |
 | Upstream-ID: 5565ef0ee0599b27f0bd1d3bb1f8a323d8274e29

cheers, Jamie
___
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

[Jamie Landeg-Jones]

Gordon Tetlow  wrote:

> I want to move the default for svn to be HTTPS. This would mean setting
> up a redirect on http://svn.freebsd.org -> https://svn.freebsd.org. For

Blimey! You're either very brave, or haven't read the thread fully! :-)
___
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

[Jamie Landeg-Jones]

Matthew Finkel  wrote:

> Why doesn't everyone have that option? Why is broadcasting a users information
> across the internet forced upon them? Shouldn't they have a choice?

They do! HTTPS already exists!

This thread is about removing HTTP and forcing HTTPS - "Why should
HTTPS be forced upon them? Shouldn't they have a choice?"

:-)

 | 21:16 (4) "/tmp" root@lapcat# svn export 
https://svn.freebsd.org/base/stable/11/usr.bin/fortune
 | Afortune
 | Afortune/datfiles
 |
 | [ ... ]
 |
 | Afortune/tools/Troff.sed
 | Exported revision 326782.

Voila! A https delivery of "fortune" ! (Confirmed via tcpdump not to be
using fallback HTTP)

cheers!
___
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

[Jamie Landeg-Jones]

John-Mark Gurney  wrote:

> So you're fine w/ all the Comcast users having to switch ISPs?  Because
> Comcast modifies traffic.  So you're now saying that if you use FreeBSD
> you can't use Comcast as your ISP?

... or they could use HTTPS, which exists.

This thread started with the proposal to remove HTTP, nothing to do with 
disabling already existing HTTPS solutions.

Cheers, 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: http subversion URLs should be discontinued in favor of https URLs

[Jamie Landeg-Jones]

"Poul-Henning Kamp"  wrote:

> simple-minded IT-liberalistic "Encrypt everything" campaign is,
> 100% as predicted, pushing governments to neuter encryption in
> order to keep the court systems working.

I agree. Unfortunately forums.freebsd.org not only went down the
'encrypt everything' route, they did so before TLS was ubiquitous
(disabling SSL2 & SSL3 way before most places)

Not directed personally at you, phk - it's just strange that forum
questions are considered more important to secure than source files!

cheers, Jamie
___
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: ntpd vulnerabilities

[Jamie Landeg-Jones]

Brett Glass br...@lariat.org wrote:

 Within my own network, I have used cron and ntpdate (even though it's
 officially deprecated) on most of the clients, querying a couple of

I think ntpdate is only deprecated because it's functionality is provided
by 'ntpd -q'

 on them. But it obviously has some drawbacks; in particular, it doesn't
 continuously correct the clocks but makes them jump at particular
 times of day.

Until recently, I'd been using this too, however, using the '-B' option to
ntpdate ('-x' to nptd) to slew the clock instead. A couple of these a day in
cron causes neglegable drift, unless your clock ain't too good!

Cheers, Jamie
___
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

Potential security issues with new top level domains?

[Jamie Landeg-Jones]

As if I needed another reason to hate the new top level domain free-for-all,
I was checking on one of my machines earlier, and forgot that I'd
renamed it, so it is no longer in my domains DNS. This was the result:

 | 2:13 (2) ~ jamie@catflap% ping android
 | PING android (127.0.53.53): 56 data bytes
 | ping: sendto: Can't assign requested address
 | ping: sendto: Can't assign requested address
 | ping: sendto: Can't assign requested address
 | ^C
 | --- android ping statistics ---
 | 3 packets transmitted, 0 packets received, 100.0% packet loss
 |
 | 2:13 (3) ~ jamie@catflap% cat /etc/resolv.conf
 | domain dyslexicfish.net
 | nameserver 127.0.0.1
 | options edns0

A quick check revealed that, as expected, unbound was first asked for
'android.dyslexicfish.net.' which returned NX, and was then asked for
'android.' which resolved the 'A' that the owners of the TLD have
configured.

Now, any scripts/binaries etc. I have that use DNS resolution always
use the FQDN with the trailing dot, so I have no personal security
worries, but I'm sure there are others out there that don't, and even
so, it could still bite for interactive use.

Yes, the 'A' returned is invalid in this case, but what's to say this
will be the case with all future new TLDs?

I realise the spec is being followed correctly, but it still seems wrong
to me that any 'host' related resource types resolve for an address at the
top level, and I was wondering what others thought about it?

Should the FreeBSD resolver ignore / not make such requests?

Should instead the functionality be built into unbound/named etc.?

Should instead TLD owners be banned from adding such records? (this still
could be abused though)

Should neither be done? I dunno, I'm just used to A/ resolves on a non 
qualified
address to either come from /etc/hosts, or be in under a domain in 
'domain/search'
from /etc/resolv.conf

The current situation seems 'wrong' and potentially troublesome to me, but I'd
be interested in what others think.

Cheers, Jamie
___
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: NEVERMIND!

[Jamie Landeg-Jones]

I've not actually used it, but I notice this in ports:

/usr/ports/sysutils/socklog:

 | svlogd has a built in log file rotation based on file size, so there is no
 | need for any cron jobs or similar to rotate the logs. Log partitions can be
 | calculated properly.
 |
 | WWW: http://smarden.org/socklog/

Cheers,
Jamie
___
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

ports requiring OpenSSL not honouring OpenSSL from ports

[Jamie Landeg-Jones]

One of the first things I do on installing a new machine is install
OpenSSL from ports. I do build with base OpenSSL due to the many programs
that depend on it, but using ports OpenSSL for ports makes things easier
to patch/update.

In the case of Heartbleed, for example, I was able to fix ports OpenSSL
much sooner than base.

In the process, however, I discovered a couple of ports that built against
base even when the port was installed. I was going to supply patches /
notify the maintainers, but first did a check, and discovered that a lot
of current ports do similar.

It turns out that this wasn't a problem specifically, but more generally,
it's possible that someone may think a port has been patched when it hasn't.

Basically what I'm asking: Shouldn't a port that uses OpenSSL *always*
build against the port if it's installed?

I realise this isn't always possible to test, especially if the port Makefile
doesn't have any openSSL configuration options, but I'd like to hear
others opinions on the matter.

[ Not crossposted to ports@ as I'm unsure onbcross-posting etiqurtte, but
  feel free to add them in if appropriate ]

Cheers,
Jamie

-- 
No sig

___
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 requiring OpenSSL not honouring OpenSSL from ports

[Jamie Landeg-Jones]

Scot Hetzel swhet...@gmail.com wrote:

 The port should use the OpenSSL port if it is installed, unless the
 port sets one of these variables in it's Makefile:

 WITH_OPENSSL_BASE
 USE_OPENSSL_BASE

 The port shouldn't be setting these variables.

Thanks. As I expected.

 Do you have a list of which ports used the OpenSSL from base, instead
 of the installed OpenSSL port?
 Could you check if they set these variables.

Well, I can only check the ones I have installed. Here's a list of some
that link against /lib/libcrypto.so.7 and/or /lib/libssl.so.7 retrieved
using the following command:

# grep -EaHlr -D skip 'libssl\.so\.7|libcrypto\.so\.7' /usr/local | awk '{print 
pkg which -oq  $1}' | sh | sort | uniq

[ N.B. 'grep -r' follows symlinks. You'd need to use 'find ... | grep ...'
  instead to be more bulletproof ]

devel/android-tools-adb
net-p2p/transmission-cli
net-p2p/transmission-daemon
net/socat
net/svnup
ports-mgmt/pkg
security/john
security/scrypt
security/trousers
sysutils/tarsnap

Again, as expected, none of these contain references to WITH_OPENSSL_BASE or
USE_OPENSSL_BASE, though I do get some ld conflict warnings in some cases
(e.g. when linking to libcurl, which does do the right thing)

 This is more of a ports issue, than a security issue.

 Post the list of affected ports to ports@, and/or submit PRs to
 correct the them.

I wanted to discuss the issue and make aware the security community
before discussing actual changes with @ports

As I said. there could be security implications if someone thinks a
patched previously vulnerable openssl port has secured all of their
other ports.

Also, it's not reliably possible to check which ports are affected
without at least downloading the distfile - some of the ports make no
reference to ssl in their ports template.

Cheers, Jamie

___
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 requiring OpenSSL not honouring OpenSSL from ports

[Jamie Landeg-Jones]

Paul Hoffman paul.hoff...@vpnc.org wrote:

 Yes, that is a reasonable expectation. I certainly had it in my head when I 
 rebuilt Sendmail+TLS after heartbleed, but I didn't think of checking it.

Been there :-) Fortunately, sendmail 'does the right thing'!

 It would be good to add such options to as many ports as possible if it can 
 be done cleanly.

This is more for ports@ than security@, but isn't mixing of 2 different 
versions potentially
problematic? I have noticed one port that links against base, but uses libcurl 
which links
against ports, so there is a version conflict there right away.

I'd expect that some magic would need to be done in the bsd.ports.Mk files, as 
you can't
necessarily tell from just scanning the port template.

 Also, note that this is not bashing on OpenSSL: given their new significant 
 funding, I would certainly expect the OpenSSL project to be 
 finding-and-fixing Heartbleed-level bugs repeatedly in the coming years. It 
 is basically impossible to fix such a bug without bad actors being able to 
 determine and exploit some of the fixes in unpatched systems.

Ditto. My concern is more general, and aligned to the POLA principle!

Cheers,
Jamie

___
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: De Raadt + FBSD + OpenSSH + hole?

[Jamie Landeg-Jones]

 I wonder how many security holes, both those known and as yet unrevealed 
 or unknown, would not be of any exploit value if in all security related 
 libraries and applications the routine to free allocated memory 
 allocation closest to the user app/library  set the newly free memory to 
 a known pattern or something from /dev/random before returning.  And, 
 similarly, a compiler option causing function returns using more than a 
 few dozen bytes of stack space to erase the newly freed stack region 

I'm probably being really dense here, and realise I can't delete this
post once sent! But

Once memory has been freed, I thought any attempt by a user process to
access it would cause a SIGSEV.

I thought the issue was with programs that inadvertantly expose (either
to read or write) other parts of their active memory.

Of course, if a process rolls it's own in-process implementation
of malloc/free, then this point is moot, but once you free memory back
to the system, isn't in no longer accessable anyway?

Cheers,
   Jamie

___
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: De Raadt + FBSD + OpenSSH + hole?

[Jamie Landeg-Jones]

Nathan Dorfman n...@rtfm.net wrote:

 free() doesn't usually free memory back to the system. It just puts
 it back onto a free list managed by libc, entirely within the
 process's address space.

 Use after free is actually a rather common type of bug -- do a web
 search on that term to see just how often it comes up.

Ahhh, so (simplifying it here somewhat), malloc/free don't always affect
the kernels own representation of the processes memory allocation, as
part of libc behaves a bit like a cache - buffering and managing requests
in userspace, so as to make things run more efficiently.

Thanks for the reply - my question wasn't quite as stupid as I feared!

Cheers, Jamie
___
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: De Raadt + FBSD + OpenSSH + hole?

[Jamie Landeg-Jones]

RW rwmailli...@googlemail.com wrote:

 It can return the physical memory, but there are a couple of caveats.
 Firstly, it can only return whole pages. Secondly, it's not returned
 instantaneously to avoid the overhead of page-faults and zeroing pages
 if that region is remalloced. It's left to the page-daemon to recover
 the physical memory in its own time, and it remains readable by it's
 previous process until it's reassigned.

Again, thanks for clearing that up for me. I wasn't all that far
off-base after all, but yours and Nathans replies make sense!

So there is a real world use for calloc after all! (though only as
a bug catching security measure - no sane program should ever read
its memory it hasn't yet written to!)

cheers, jamie

___
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: De Raadt + FBSD + OpenSSH + hole?

[Jamie Landeg-Jones]

hcoin hc...@quietfountain.com wrote:

 local variables) harms performance.   It's also true doing both of these 
 things would not fix the flaw that 'opened the window' onto these data.  
 However it is true that doing so would make the exploit valueless as 
 'opening a window' onto erased data would reveal nothing and could erase 
 trojan/virus 'hijack via code-injection then trampoline' opportunities.

In the heartbleed case, was the bug returning stale freed memory, though?
Couldn't it just as easily have been that the over-read was returning any
other memory that the process has had allocated for other variables - data
that was still in use?

 If the variable stack and free() functions erased data spaces, there 
 would be no security value in having application edge malloc effectively 
 be calloc.

Yeah. I had wrongly assumed that this was a throwback to more innocent
days, and that these days, malloced space was effectively cleared by every
sane OS, but due to backwards compatibility, the spec only defines calloc
as acually clearing data, so you should never assume malloced memory was
cleared, even though effectively it is these days.

But Nathan and RW helpfully showed me where my reasoning failed!

 There may be marginal security value in having OS edge free() erase data 
 before subsequent OS edge malloc of the same page to a process owed by a 
 different userid.

Now this I don't get. Marginal? Surely in this case, this is a MUST.
Otherwise we'd continually be getting local users getting data they
shouldn't  Every machine would be a 'heartbleed' for local users,
even when running bug free code! I'd even extend this policy to different
processes - even with the same id, because, of course, many daemons
spawn children that deal with different connections simultaneously.
(But of course in this case any leak would be down to bad programming
if data leaks were discovered to be exploitable.)

But yeah, surely if the UID (or more accurately, the EUID) were different
but the data wasn't erased by the system prior to malloc, a leak
would be unpreventable (unless, of course, the careful programmer never
frees data, until he/she has erased it themselves beforehand. And who
does that?

 This entire discussion, (clear-on-free and 
 clear-stack-on-function-return) are resource heavy ways of managing 
 complexity.  It is for the community to decide whether it is 'worth it' 
 on a case by case basis given there is no way to prove a program 
 'correct' from a security perspective.

I agree. More generally, all exploit busting mechanisms add to complexity
and resources, whether it's DNS randomizing outgoing udp ports, or stack
protection/pro police/canaries etc.

You have to make a judgement call based between the protection of your software
against speed, throwing into the equation the competence of your
programming team!

cheers, Jamie

___
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: De Raadt + FBSD + OpenSSH + hole?

[Jamie Landeg-Jones]

Bryan Drewery bdrew...@freebsd.org wrote:

 On 4/14/2014 7:32 AM, Jamie Landeg-Jones wrote:
  
  As to the specific question, I don't think his ego would allow a bug
  in openssh to persist, so even if it does, I'd suspect it's not too
  serious (or it's non-trivial to exploit), and it's related to FreeBSD
  produced 'glue'.
  
  This is total guesswork on my part, but I'd therefore assume he was
  talkining about openssh in base, rarther than openssh-portable in
  ports.
  

 As the maintainer of the port I will say that your security decreases
 with each OPTION/patch you apply. I really would not be surprised if one
 of the optional patches available in the port had issues.

A. good point. I forgot about third-party patches.

Yeah, if he's not just blowing smoke, that would make the most sense.

I don't reckon he'd leave an exploit open if it was purely related to
the unpatched source - even if there is some quirk which only makes
it only applicable to FreeBSD.

Still, by not revealing it, he's only potentially hurting the users.

I wonder how many blackhats are going to use this thread as a heads-up?

Cheers, Jamie
___
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: De Raadt + FBSD + OpenSSH + hole?

[Jamie Landeg-Jones]

Matt Dawson m...@chronos.org.uk wrote:

 My first thought when I saw this was ego over ethics, which says more
 about Theo than FreeBSD.

Totally.

I know Theo has a reputation for being 'difficult', but in my opinion,
this outburst really calls into question his perceived motivations
regarding secure software.

As to the specific question, I don't think his ego would allow a bug
in openssh to persist, so even if it does, I'd suspect it's not too
serious (or it's non-trivial to exploit), and it's related to FreeBSD
produced 'glue'.

This is total guesswork on my part, but I'd therefore assume he was
talkining about openssh in base, rarther than openssh-portable in
ports.

___
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: ftpd security issue ?

[Jamie Landeg Jones]

  Are the following steps enough to prevent me?
 
  # for user in user1 user2  ; do
  mkdir -p ~$user/lib ~$user/usr/lib ~$user/etc
  chflags sunlink,schg ~$user/lib ~$user/usr ~$user/usr/lib ~$user/etc
  done
  #

 Yes that should be sufficient workaround.

I'd modify that to also check that the directories don't already exist,
and delete/rename them if they do.

Currently, (if you ignore error messages) your script will not fix users
who already potentially exploit the issue.

Cheers,
Jamie
___
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: Rooting FreeBSD , Privilege Escalation using Jails (P??????tur)

[Jamie Landeg Jones]

 +1

I did mention the bikeshed earlier ! :D
___
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: Rooting FreeBSD , Privilege Escalation using Jails (P??????tur)

[Jamie Landeg Jones]

 Why not ? What sense does having -r+x make?

Because on some old systems I used to work with, you needed +x for it
to work. Now I know  works on FreeBSD, I'll try to remember to
use that instead!
___
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: Rooting FreeBSD , Privilege Escalation using Jails (P??????tur)

[Jamie Landeg Jones]

 Dumb question: the jail command can refuse to run unless the
 parent of a jail root is 0700. Would that work? No kernel hack
 required.

Haha, all talking about kernel hacks and so on, and yet, to me,
that seems the simplest, but ALSO, the most elegent solution.

I'd have some override flag that could be set for those who's jails
are directly under an important folder, e.g. /usr/my-jail-name/
so that those unable to change straight away can set an rc/sysctl
flag rather than have to hack the code..

Is this turning into a bikeshed discussion?

___
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: Rooting FreeBSD , Privilege Escalation using Jails (P�tur)

[Jamie Landeg Jones]

  A jail won't work for not-root users if the jail root directory is chmod 
  700 - although
  there is obviously a 'chroot' running withing the jail, the jailed user 
  still needs
  to have read permission from the hosts / -- chmod 700 therefore locks all 
  non-root
  users out.
 

 It's weird - I don't remember having such problem after setting jails'
 root directory permission to 700. I don't have the system anymore so I
 can't verify it just yet.

I just tried it again (Freebsd 8.2) and I am wrong.

Setting 700 on the jail root does indeed mess things up. But setting it on
the parent (e.g. /usr/jails), and things are fine.

Stupidly of me, that makes perfect sense. The non-privileged user needs
read access to the jails /

Sorry for the spam
___
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: Rooting FreeBSD , Privilege Escalation using Jails (P�tur)

[Jamie Landeg Jones]

 All the same, I've sent a PR [1] with some doc patches to make people
 more aware of this -- fulfilling my promise of 2+ years ago :S

 Thanks!

 Chris

 [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=156853

Um. Some problems here.

A jail won't work for not-root users if the jail root directory is chmod 700 - 
although
there is obviously a 'chroot' running withing the jail, the jailed user still 
needs
to have read permission from the hosts / -- chmod 700 therefore locks all 
non-root
users out.

I would suggest you add to the docs about the UID clash problem - untrusted 
users on the host
shouldn't have the same UID/GID as jailed users, as they will have access to 
their files.

And of course, the bit mentioned earlier where an untrusted jail user with 
jail-root access
should NEVER have access to the host!o

Among other things, my password file in both jails and the host has this line:

# 8000 to   -  Reserved for use within jails - do not use in main host!

cheers,
Jamie

___
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: mbuf security advisory for 7.2-RELEASE?

[Jamie Landeg Jones]

  Just to confirm, 7.2-RELEASE is not effected by this issue?  Just
  seems odd that all versions of 7.x are listed minus 7.2-RELEASE.
 
  7.2-RELEASE was out of support when the advisory was issued.
  It *is* vulnerable.

 Thought so!  Thanks guys!  It just wasn't clear to me.

Easy mistake to make, seeing as 7.1 is not EoL, but 7.2 is!

___
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-09:16.rtld

[Jamie Landeg Jones]

 Jamie Landeg Jones ha scritto:

  So, yes, FreeBSD 6.3-RELEASE upwards are affected - FreeBSD 6.2 isn't.

 Thanks.
 So, is a patch on the way for 6.[34] too?
 I guess the sec team just wanted to get out what they had as soon as 
 possible and I agree with them and thanks them.
 But I just need to plan... :-)

I don't know - are they still supported?

Anyway, I just made this patch. I don't have any 6.X machines to test it on,
but it should work on 6.3 and 6.4 (put it this way, if it doesn't work it
will fail to compile, rather than break your machine!):

Incidently, I am not part of the offical freebsd team.

cheers,
Jamie

--- rtld.c.orig 2007-07-14 20:04:00.0 +0100
+++ rtld.c  2009-12-03 17:29:58.0 +
@@ -349,11 +349,12 @@
  * future processes to honor the potentially un-safe variables.
  */
 if (!trust) {
-unsetenv(LD_ PRELOAD);
-unsetenv(LD_ LIBMAP);
-unsetenv(LD_ LIBRARY_PATH);
-unsetenv(LD_ LIBMAP_DISABLE);
-unsetenv(LD_ DEBUG);
+if (unsetenv(LD_ PRELOAD) || unsetenv(LD_ LIBMAP) ||
+   unsetenv(LD_ LIBRARY_PATH) || unsetenv(LD_ LIBMAP_DISABLE) ||
+   unsetenv(LD_ DEBUG)) {
+   _rtld_error(environment corrupt; aborting);
+   die();
+   }
 }
 ld_debug = getenv(LD_ DEBUG);
 libmap_disable = getenv(LD_ LIBMAP_DISABLE) != NULL;
___
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-09:16.rtld

[Jamie Landeg Jones]

___
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-09:16.rtld

[Jamie Landeg Jones]

 The discussion you mention presumably involves checking out the patched 
 version of rtld sources from 7.x or 8 and building+installing that under 6.x. 
  Given that 6.x rtld is the older one with a longer history of security 
 review and doesn't have the current known vulnerability, whereas the new 
 version just got patched and might have other issues lurking, I am happy 
 sticking with 6.x version on my 6.x boxes.

A, I see. I was looking at the source of rtld.c to check when the change 
was made that allowed this vulnerability to exist, and that change was from 6.3 
onwards.

But it seems it's the changes to getenv/unsetenv from 7.0 onwards that cause 
this to be an exploitable issue.

However, I'd still apply the patch in case some other way to exploit the 
non-checking of the unsetenv return status crops up elsewhere.

It can't do any harm.

___
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-09:16.rtld

[Jamie Landeg Jones]

 On 12/03/2009 08:01 PM, Pieter de Boer wrote:
  Jamie Landeg Jones wrote:
 
  However, I'd still apply the patch in case some other way to exploit
  the non-checking of the unsetenv return status crops up elsewhere.
 
  It can't do any harm.
  
  The problem with that is, on 6.x, unsetenv() returns 'void', so there's
  no return value to check on.

As Pieter pointed out, unsetenv returns 'void', so checking for a return
value (like that patch does) doesn't make sense.

Sorry for wasting your time - the patch is not necessary (and won't even work)
on 6.X systems, as you've discovered.

Your system is safe from this attack, and any related ones.

Jamie

___
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