similar to: Non-executable stack

Hi there, I was looking for stack smashing protection under freebsd, so i found libparanoia (/usr/ports/security/libparanoia), i had only one question using the normal 'make install' (so no copy-to-libc). If i add in /ert/make.conf: CFLAGS= -O -pipe -lparanoia -L/usr/local/lib COPTFLAGS= -O -pipe -lparanoia -L/usr/local/lib Will EVERYTHING build from that time (including

Hi there, I'm still running 6.2 on various servers without any tweaks (GENERIC kernel, binary updates via freebsd-update etc.) but lots of ports (apache, postgresql, diablo-jdk etc.) and would like to use stack smashing protection in order to harden my boxes and avoid many potential exploits. I've known about ProPolice/SSP for a while now (from the Gentoo world) and am aware that

I was wondering if there's any non-executable stack patch for FreeBSD's kernel. I searched in google but all I got was some questions in freebsd-security back from 2001 and an answer saying someone heard about a project like this, but no information at all. Is there any patch like PaX or Openwall available for FreeBSD? I dont want to discuss if its useless or not since there're a

We still have MD5 as our default password hash, even though known-hash attacks against MD5 are relatively easy these days. We've supported SHA256 and SHA512 for many years now, so how about making SHA512 the default instead of MD5, like on most Linux distributions? Index: etc/login.conf =================================================================== --- etc/login.conf (revision

I figure some one here may find this interesting. I just begun work on allowing a smb home directory to be automounted upon login. -------------- next part -------------- A non-text attachment was scrubbed... Name: pam_exec.c.diff Type: text/x-patch Size: 213 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20070519/19e6bd01/pam_exec.c.bin

Login seems to be ignoring my /etc/login.access settings. I have the following entries (see below) in my login.access, yet any new user (not in the wheel group) is still allowed to login. What am I missing? # $FreeBSD: src/etc/login.access,v 1.3 1999/08/27 23:23:42 peter Exp $ # -:ALL EXCEPT wheel:console -:ALL EXCEPT wheel:ALL Thanks, -- Scott Gerhardt, P.Geo. Gerhardt Information

Take the usual precautions when upgrading. Also note that I have changed some configuration defaults: the server no longer accepts protocol version 1 nor password authentication by default. If your ssh client does not support ssh protocol version 2 or keyboard-interactive authentication, the recommended measures are: 1) get a better client 2) get a better client (I mean it) 3) get a better

Lesley Kimmel <lesley.j.kimmel at gmail.com> writes: > So I probably shouldn't have said "arbitrary" script. What I really > want to do is to present a terms of service notice (/etc/issue). But I > also want to get the user to actually confirm (by typing 'y') that > they accept. If they try to exit or type anything other than 'y' they > will be

Hello, I am interested in an ssh that is not interactive in requesting the password, i.e, whereas I can specify the password in the command line when calling SSH. I have wondered how such a feature has not been included in such a good client, as it seems there are many (and I have searched for this) people require this capability for their scripts/automation. I understand the possibility of

Hi. I experimented a bit with collecting entropy from the time it takes for device_attach() to run (in CPU cycles). It seems that those times have enough variation that we can use it for entropy harvesting. It happens even before root is mounted, so pretty early. On the machine I'm testing it, which has minimal kernel plus NIC driver I see 75 device_attach() calls. I'm being very careful

Nico Kadel-Garcia <nkadel at gmail.com> writes: > Dag-Erling Sm?rgrav <des at des.no> writes: > > Some OS distributions (FreeBSD, RHEL / CentOS, probably Fedora) have > > X11Forwarding enabled by default. > I'm not sure I see your point. With X11Forwarding off by default, one would assume that it is only enabled on a case-by-case basis for users or groups who

Cf. http://seclists.org/fulldisclosure/2008/Jul/0090.html This Mrdkaaa character claims to have exploited this, but does not say how. The issue is that if do_pam_account() fails, do_authloop() will call packet_disconnect() with loginmsg as the format string (classic printf(foo) instead of printf("%s", foo) bug). The stuff that do_authloop() appends to loginmsg is harmless (the user

Nico Kadel-Garcia <nkadel at gmail.com> writes: > I'm just trying to figure out under what normal circumstances a > connection with X11 forwarding enabled wouldn't be owned by a user who > already has normal system privileges for ssh, sftp, and scp access. Some OS distributions (FreeBSD, RHEL / CentOS, probably Fedora) have X11Forwarding enabled by default. DES --

Hello, I'm was looking through handbook and wikipedia and it appears FreeBSD doesn't support hardware (nor software) nx bit. There also doesn't seem to be any support for TPM (Trusted Platform Module). I was wondering if it is due to a general lack of interest and/or personal preference (gcc?) or are there other issues. The reason I'm asking is I'm currently doing a MSc degree

All, Given the amount of NULL-pointer dereference vulnerabilities in the FreeBSD kernel that have been discovered of late, I've started looking at a way to generically protect against the code execution possibilities of such bugs. By disallowing userland to map pages at address 0x0 (and a bit beyond), it is possible to make such NULL-pointer deref bugs mere DoS'es instead of code

Nico Kadel-Garcia <nkadel at gmail.com> writes: > Dag-Erling Sm?rgrav <des at des.no> writes: > > It is relatively trivial to write a PAM module to do that. > Which will have the relevant configuration overwritten and disabled > the next time you run "authconfig" on Red Hat based sysems. I'm not > sure if this occurs with other systems, but tuning PAM is

/etc/login.access does not work 100% over ssh. I have the following line in login.access -:ray:ALL EXCEPT LOCAL Which I believe means the user 'ray' can not login from anywhere unless it is a local login. So, I tested it over ssh from a remote box tigger@piglet:~% ssh ray@sonic.cbnmediaX.com.au Password: Password: Password: ray@sonic.cbnmediaX.com.au's password: Last login: Sat

Has anyone got the pam_chroot module to successfully work in FreeBSD? I have FreeBSD 5.2-RELEASE installed. I copied the appropriate binaries and libraries into my chroot, I can chroot -u test -g test /home/test /usr/local/bin/bash and it works perfectly. So now I am trying to get the pam module to work. I added session required pam_chroot.so debug into the

Dear all, Browsing through the securityfocus vulnerability database I found two items, that might interesting for the FreeBSD community: 1. GNU GNATS Syslog() Format String Vulnerability http://www.securityfocus.com/bid/10609 GNATS is vital part of the PR handling of FreeBSD. I think security officers should contact developers of GNU GNATS about this issue to resolve the potential problem.

--- mux.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/mux.c b/mux.c index d90605e..fa796bd 100644 --- a/mux.c +++ b/mux.c @@ -1195,6 +1195,7 @@ muxserver_listen(void) close(muxserver_sock); muxserver_sock = -1; } + xfree(orig_control_path); xfree(options.control_path); options.control_path = NULL; options.control_master = SSHCTL_MASTER_NO;