> 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 & Tha
> 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 wi
> 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 a
___
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"
> 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 t
>
> 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.
> >>
> &g
> 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.
> >> 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
> 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 di
> > 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.
>
> 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 (s
> 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 t
> 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
htt
> 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 tha
> 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
> +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"
> > 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 a
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.
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-t
> 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
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
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
"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
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 Op
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 us
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
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/so
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 b
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;
"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, th
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 re
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 the
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
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 "poss
34 matches
Mail list logo
