Re: Possible break-in attempt?

2018-07-20 Thread 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

2017-12-14 Thread 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

2017-12-11 Thread 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

2017-12-11 Thread 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

2017-12-05 Thread 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

2014-12-22 Thread Jamie Landeg-Jones
Brett Glass  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?

2014-11-16 Thread 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!

2014-05-27 Thread 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"


Re: ports requiring OpenSSL not honouring OpenSSL from ports

2014-04-27 Thread Jamie Landeg-Jones
Paul Hoffman  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: ports requiring OpenSSL not honouring OpenSSL from ports

2014-04-27 Thread Jamie Landeg-Jones
Scot Hetzel  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"


ports requiring OpenSSL not honouring OpenSSL from ports

2014-04-27 Thread 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: De Raadt + FBSD + OpenSSH + hole?

2014-04-20 Thread Jamie Landeg-Jones
"hcoin"  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?

2014-04-20 Thread Jamie Landeg-Jones
RW  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?

2014-04-20 Thread Jamie Landeg-Jones
Nathan Dorfman  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?

2014-04-20 Thread 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?

2014-04-19 Thread Jamie Landeg-Jones
Bryan Drewery  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?

2014-04-14 Thread Jamie Landeg-Jones
Matt Dawson  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 ?

2011-12-11 Thread 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)

2011-05-11 Thread 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)

2011-05-10 Thread Jamie Landeg Jones
> It is still required for .. to work.
>
> For example, if the /usr directory on / is 700 but the directory on the
> mounted filesystem is 755, everyone can use pathnames under /usr but only
> root can use /usr/.. which is confusing and undesirable.
>
> > I always make mount-points 0111 these days
>
> I'd recommend to keep doing that :)

Wow! Good catch! I missed that!

And I note that ".." doesn't even appear on an ls -a

That tells you too, Chris Rees :-)

Ok, I'll stick with 0111 - also, the reason I use 0111 instead of just
the default 755 (or whatever) is that it's an alert to me if some mount isn't
mounted for whatever reason.

To me, 0111 means mount-point only, period.

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)

2011-05-10 Thread 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)

2011-05-10 Thread 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)

2011-05-10 Thread Jamie Landeg Jones
> It used to confuzzle sysadmins on SUNos when the mount point was
> 0700.  The underlying mode disapeared when the mount was made, but it
> was still being enforced. Suddenly no one but root could use say /usr
> even though it was apparently 0755

I remember that happening! I thought it was like that on FreeBSD too,
but if it was, it isn't any longer!

I always make mount-points 0111 these days
___
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)

2011-05-10 Thread Jamie Landeg Jones

> Do you know if there is a way that chmod on / from within the jail could 
> be prevented easily without breaking something ? Maybe not failing but 
> falling though and return 0 for any operation with the sole argument of /.

Enforcing 700 on the jail root?

Whilst I was wrong on chmod 700 on (say) /usr/jails it is still the case
that the root directory of the jail itself (/usr/jail/jailname) has to
be 755 for non-root processeses within the jail to access the filesystem!

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)

2011-05-09 Thread 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)

2011-05-07 Thread 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?

2010-11-18 Thread 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

2009-12-03 Thread Jamie Landeg Jones
> Any body can explain why no credit section for this advisory?

Probably because the person who found the bug didn't notify the security
team, but posted it on a public list to gain l33t points.
___
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

2009-12-03 Thread 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"


Re: FreeBSD Security Advisory FreeBSD-SA-09:16.rtld

2009-12-03 Thread 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

2009-12-03 Thread 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

2009-12-03 Thread Jamie Landeg Jones
> So, what would be 'best of practice' to apply the patch to 6.3-RELEASE 
> upwards -- is the FreeBSD-7 patch applicable or should one wait for an 
> official announcement?

I just noticed that the patch I replied with is basically the same as the
Freebsd-7 patch that was posted.

However, as has already been discussed, 6.X isn't exploitable by the posted
bug, because the changes to the env functions that allow the exploit to work
didn't happen until 7.X

However, I would certainly apply the patch anyway - basically, the old way
was just blindly unsetting environment variables and blindly assuming the
unsetting worked.

The new way does exactly the same unsetting, but if any of the unsets fails
(due to corrupt environment) it aborts.

Just in case there is some other way of exploiting the fact that rtld.c didn't
check whether unsetenv was successful (which I bet people are now looking for)
I'd apply the patch to 6.3 and 6.4 also, just to be sure.

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: FreeBSD Security Advisory FreeBSD-SA-09:16.rtld

2009-12-03 Thread 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

2009-12-03 Thread Jamie Landeg Jones
> Sorry, this might seem a stupid question, but...
> In several places I read that FreeBSD 6.x is NOT affected; however, I 
> heard some people discussing how to apply the patch to such systems.
> So, I'd like to know for sure: is 6.x affected? Is another patch on the 
> way for it?
>
>   bye & Thanks
>   av.

The change that introduced the bug was made as follows:

 | Revision 1.124: download - view: text, markup, annotated - select for diffs
 | Thu May 17 18:00:27 2007 UTC (2 years, 6 months ago) by csjp
 | Branches: MAIN
 | CVS tags: RELENG_7_BP, RELENG_7_0_BP, RELENG_7_0_0_RELEASE, RELENG_7_0
 | Branch point for: RELENG_7
 | Diff to: previous 1.123: preferred, colored
 | Changes since revision 1.123: +20 -10 lines
 | 
 | In the event a process is tainted (setuid/setgid binaries), un-set any
 | potentially dangerous environment variables all together. It should be
 | noted that the run-time linker will not honnor these environment variables
 | if the process is tainted currently. However, once a child of the tainted
 | process calls setuid(2), it's status as being tainted (as defined by
 | issetugid(2)) will be removed. This could be problematic because
 | subsequent activations of the run-time linker could honnor these
 | dangerous variables.
 | 
 | This is more of an anti foot-shot mechanism, there is nothing I am
 | aware of in base that does this, however there may be third party
 | utilities which do, and there is no real negative impact of clearing
 | these environment variables.
 | 
 | Discussed on:secteam
 | Reviewed by: cperciva
 | PR:  kern/109836
 | MFC after:   2 weeks

This was also ported MFC'd into 6.3 onwards:

 | Revision 1.106.2.7: download - view: text, markup, annotated - select for 
diffs
 | Sat Jul 14 19:04:00 2007 UTC (2 years, 4 months ago) by csjp
 | Branches: RELENG_6
 | CVS tags: RELENG_6_4_BP, RELENG_6_3_BP, RELENG_6_3_0_RELEASE, RELENG_6_3
 | Branch point for: RELENG_6_4
 | Diff to: previous 1.106.2.6: preferred, colored; branchpoint 1.106: 
preferred, colored; next MAIN 1.107: preferred, colored
 | Changes since revision 1.106.2.6: +20 -10 lines
 | 
 | MFC rtld.c revision 1.124
 | 
 | Unset potentially harmful environment variables.
 | 
 | Discussed on:seacteam
 | PR:  kern/109836


So, yes, FreeBSD 6.3-RELEASE upwards are affected - FreeBSD 6.2 isn't.
___
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"