Re: Patch from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=179721 broke some application (xterm, pidign)

[Pedro Giffuni]

Hello Vitalij;


Hello.

After updating my system to 11.0-ALPHA2 #20 r301583
I'm found that at last some application is broken.

here backtrace for xterm

#0  0x0008022d48b4 in mbsrtowcs_l () from /lib/libc.so.7
[New Thread 804816000 (LWP 102346/)]
(gdb) bt
#0  0x0008022d48b4 in mbsrtowcs_l () from /lib/libc.so.7
#1  0x0008022d1b4f in strcoll_l () from /lib/libc.so.7
#2  0x0008022d0ddf in __collate_range_cmp () from /lib/libc.so.7
#3  0x0008022cf6ce in vfscanf () from /lib/libc.so.7
#4  0x0008022b0114 in vsscanf () from /lib/libc.so.7
#5  0x0008022aee6d in sscanf () from /lib/libc.so.7
#6  0x004523a3 in ?? ()
#7  0x00430edd in ?? ()

for pidgin it's look same.

It seems that patch not fully care about all cases where function like 
__collate_range_cmp used.

Manualy rollback changes from 
http://svnweb.freebsd.org/base?view=revision=301461  fix the problem 
for now.



Thank you very much for the report.
I am testing the fix (replacing __collate_range_cmp in vfscanf()),
right now.

Pedro.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD_HEAD_i386 - Build #3370 - Still Failing

[jenkins-admin]

FreeBSD_HEAD_i386 - Build #3370 - Still Failing:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3370/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3370/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3370/console

Change summaries:

301775 by cy:
Clarify the wording to be more accurate.

Approved by:re@ (gjb)
MFC after:  1 week
X-MFC with: r301773

301773 by cy:
Update the man ipf.8 man page to accurately reflect that the -6
option is a noop and only here for backward compatibility.

MFC after:  1 week



The end of the build log:

[...truncated 79943 lines...]
cc -DPROF -O2 -pipe   -I/usr/src/lib/libc/include 
-I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS  
-D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa 
-I/usr/src/lib/libc/../../contrib/libc-vis -DINET6 -I/usr/obj/usr/src/lib/libc 
-I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE 
-I/usr/src/lib/libc/../libmd -I/usr/src/lib/libc/../../contrib/jemalloc/include 
-I/usr/src/lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime 
-I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN 
-I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -MD  
-MF.depend.cap_getmode.po -MTcap_getmode.po -std=gnu99 -fstack-protector-strong 
-Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized 
-Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-unused-local-typedef -Wno-switch -Wno-switch-enu
 m -Wno-knr-promoted-parameter  -Qunused-arguments  -I/usr/src/lib/libutil 
-I/usr/src/lib/msun/i387 -I/usr/src/lib/msun/x86 -I/usr/src/lib/msun/src   -c 
cap_getmode.S  -o cap_getmode.po
--- pdfork.po ---
cc -DPROF -O2 -pipe   -I/usr/src/lib/libc/include 
-I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS  
-D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa 
-I/usr/src/lib/libc/../../contrib/libc-vis -DINET6 -I/usr/obj/usr/src/lib/libc 
-I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE 
-I/usr/src/lib/libc/../libmd -I/usr/src/lib/libc/../../contrib/jemalloc/include 
-I/usr/src/lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime 
-I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN 
-I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -MD  
-MF.depend.pdfork.po -MTpdfork.po -std=gnu99 -fstack-protector-strong 
-Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized 
-Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr
 -promoted-parameter  -Qunused-arguments  -I/usr/src/lib/libutil 
-I/usr/src/lib/msun/i387 -I/usr/src/lib/msun/x86 -I/usr/src/lib/msun/src   -c 
pdfork.S  -o pdfork.po
--- pdkill.po ---
cc -DPROF -O2 -pipe   -I/usr/src/lib/libc/include 
-I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS  
-D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa 
-I/usr/src/lib/libc/../../contrib/libc-vis -DINET6 -I/usr/obj/usr/src/lib/libc 
-I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE 
-I/usr/src/lib/libc/../libmd -I/usr/src/lib/libc/../../contrib/jemalloc/include 
-I/usr/src/lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime 
-I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN 
-I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -MD  
-MF.depend.pdkill.po -MTpdkill.po -std=gnu99 -fstack-protector-strong 
-Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized 
-Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr
 -promoted-parameter  -Qunused-arguments  -I/usr/src/lib/libutil 
-I/usr/src/lib/msun/i387 -I/usr/src/lib/msun/x86 -I/usr/src/lib/msun/src   -c 
pdkill.S  -o pdkill.po
--- all_subdir_kerberos5 ---
--- ks_p12.po ---
cc  -pg  -O2 -pipe 
-I/usr/src/kerberos5/lib/libhx509/../../../crypto/heimdal/lib/hx509 
-I/usr/src/kerberos5/lib/libhx509/../../../crypto/heimdal/lib/hx509/ref 
-I/usr/src/kerberos5/lib/libhx509/../../../crypto/heimdal/lib/asn1 
-I/usr/src/kerberos5/lib/libhx509/../../../crypto/heimdal/lib/wind 
-I/usr/src/kerberos5/lib/libhx509/../../../crypto/heimdal/lib/roken -I.   
-DHAVE_CONFIG_H -I/usr/src/kerberos5/lib/libhx509/../../include -MD  
-MF.depend.ks_p12.po -MTks_p12.po -std=gnu99 -fstack-protector-strong
-Qunused-arguments  -c 
/usr/src/kerberos5/lib/libhx509/../../../crypto/heimdal/lib/hx509/ks_p12.c -o 
ks_p12.po
--- all_subdir_lib ---
--- pdgetpid.po ---
cc -DPROF -O2 -pipe   

FreeBSD_HEAD_i386 - Build #3369 - Failure

[jenkins-admin]

FreeBSD_HEAD_i386 - Build #3369 - Failure:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3369/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3369/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3369/console

Change summaries:

301771 by imp:
New NVMe front end (nda).

301770 by pfg:
rpcbind(8): Make use of some xdr_* macros.

xdr_rpcproc, xdr_rpcprog and xdr_rpcvers were broken in older
versions of FreeBSD but fixed in r296394.  Give them some use
hoping they help make the code somewhat more readable.

301769 by pfg:
libc/rpc: Make use of some xdr_* macros. (part 2)

xdr_rpcproc, xdr_rpcprog and xdr_rpcvers were broken in older
versions of FreeBSD but fixed in r296394.  Give them some use
hoping they help make the code somewhat more readable.

301768 by jilles:
utimes(2),utime(3): Add deprecation in favour of utimensat(2) and futimens(2).

Setting time by seconds or microseconds may cause unexpected effects
especially if sysctl vfs.timestamp_precision=3 (not default).

Calling the obsolete functions with NULL timestamps is acceptable.

301767 by adrian:
[ath] add a placeholder event for debuggin EDMA TX FIFO push events.

Some later code I'll commit pushes lists of frames into the EDMA TX
FIFO, rather than a single frame at a time.  The CABQ code already
pushes frame lists, but it turns out we should actually be doing it
in general or performance tanks. :(

301766 by adrian:
[ath] report node queue overflows.

I need to also update athstats to report this too.

301765 by jilles:
install: When preserving timestamps, also copy the nanoseconds part.

Now that we have utimensat in -legacy, install(1) can use it.

This is a revert of r299942 which is itself a revert of r299850.

301764 by jamie:
Fix a vnode leak when giving a child jail a too-long path when
debug.disablefullpath=1.

301763 by jilles:
build: Add legacy support for futimens() and utimensat().

In order to allow using utimensat() in install(1), add futimens() and
utimensat() to -legacy.

The files futimens.c and utimensat.c are modified copies of the files under
lib/libc/sys/ since the libc versions use symbols that do not exist in the
libc on the build system (sys_futimens and sys_utimensat) . I expect the
next non-sweeping change to both sets of files to be to delete them, anyway.

This will allow reverting r299942 (which is a revert of r299850) enabling
nanosecond timestamps in install(1).

Reviewed by:bdrewery

301762 by avos:
urtwn: reinstall group keys on every device startup.

Since key table is cleared on every device shutdown,
static WEP keys (which are set only once) need to be
reinstalled manually every time when device starts running.

Tested with RTL8188EU, STA (all ciphers) / IBSS (WPA-none) modes.



The end of the build log:

[...truncated 79403 lines...]
--- all_subdir_lib ---
--- _poll.po ---
cc -DPROF -O2 -pipe   -I/usr/src/lib/libc/include 
-I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS  
-D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa 
-I/usr/src/lib/libc/../../contrib/libc-vis -DINET6 -I/usr/obj/usr/src/lib/libc 
-I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE 
-I/usr/src/lib/libc/../libmd -I/usr/src/lib/libc/../../contrib/jemalloc/include 
-I/usr/src/lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime 
-I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN 
-I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -MD  
-MF.depend._poll.po -MT_poll.po -std=gnu99 -fstack-protector-strong 
-Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized 
-Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-p
 romoted-parameter  -Qunused-arguments  -I/usr/src/lib/libutil 
-I/usr/src/lib/msun/i387 -I/usr/src/lib/msun/x86 -I/usr/src/lib/msun/src   -c 
_poll.S  -o _poll.po
--- all_subdir_gnu ---
--- data.o ---
cc  -O2 -pipe   -I. -I/usr/src/gnu/usr.bin/dtc 
-I/usr/src/gnu/usr.bin/dtc/../../../contrib/dtc 
-I/usr/src/gnu/usr.bin/dtc/../../../sys/contrib/libfdt -g -MD  
-MF.depend.data.o -MTdata.o -std=gnu99 -fstack-protector-strong 
-Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized 
-Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-unused-local-typedef -Wno-switch -Wno-switch-enum 
-Wno-knr-promoted-parameter  -Qunused-arguments  -c 
/usr/src/gnu/usr.bin/dtc/../../../contrib/dtc/data.c -o data.o
--- all_subdir_lib ---
--- _ppoll.po ---
cc -DPROF -O2 -pipe   -I/usr/src/lib/libc/include 
-I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS  
-D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa 

Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

[Matthew Seaman]

On 09/06/2016 18:34, Craig Rodrigues wrote:
> There is still value to ypldap as it is now, and getting feedback from
> users (especially Active Directory) would be very useful.
> If someone could document a configuration which uses IPSEC or OpenSSH
> forwarding, that would be nice.
> 
> In future, maybe someone in OpenBSD or FreeBSD will implement things like
> LDAP over SSL.

What advantages does ypldap offer over nss-pam-ldapd (in ports) ?
nss-pam-ldapd can use both ldap+STARTTLS or ldaps to encrypt data in
transit, and I find it works very well for using OpenLDAP as a central
account database.  I believe it works with AD, but haven't tried that
myself.

Cheers,

Matthew




signature.asc
Description: OpenPGP digital signature

Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

[Craig Rodrigues]

On Wed, Jun 8, 2016 at 11:41 PM, Xin Li  wrote:

>
> (I think the current implementation
> would do everything with plaintext protocol over wire, so while it
>

You are correct.  This document http://puffysecurity.com/wiki/ypldap.html#2
states:

#
# ypldap cant use SSL or SASL...
# You must allow unsecured authentication with the following line
# Then setup OpenIKED VPN or use OpenSSH Socket or Port Forwording
#


There is still value to ypldap as it is now, and getting feedback from
users (especially Active Directory) would be very useful.
If someone could document a configuration which uses IPSEC or OpenSSH
forwarding, that would be nice.

In future, maybe someone in OpenBSD or FreeBSD will implement things like
LDAP over SSL.

--
Craig
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT: bhyve and Kernel SamePage Mergin

[Shawn Webb]

Hey David,

I'm responding inline.

On Thu, Jun 09, 2016 at 09:18:40AM +0100, David Chisnall wrote:
> If this paper is the one that I think it is, then I was one of the reviewers. 
>  Their attack is neat, but it depends quite a lot on being able to 
> deterministically trigger deduplication.  Their proof-of-concept exploit was 
> on Windows (and JavaScript attack was really fun) and I???m not convinced 
> that it would work reliably on Linux or VMWare ESX, which both defer 
> deduplication for as long as possible to avoid NUMA-related overheads.
> 
> We don???t currently have a FreeBSD implementation, but if someone wanted to 
> provide one then a defence against this attack would be fairly simple: count 
> the number of CoW faults that a process is receiving and if it reaches a 
> certain threshold then remove all of its memory from the set of eligible 
> pages.  The attack relies on being able to repeatedly trigger CoW faults and 
> time whether they occur, with the same set of pages.  At least some existing 
> implementations will make this impossible as these pages will repeatedly be 
> deduplicated and then duplicated and this is already a pathological case that 
> most memory deduplication implementations need to handle (as well as being a 
> security hole, it???s also a big performance killer).

Competely agreed. This is a "nothing to see here" situation. The paper
simply doesn't apply to FreeBSD.

> 
> Kib has been working on ASLR for FreeBSD (I think it???s in 11?), but at this 
> point it???s more of a checkbox item than a serious mitigation technique.  It 
> adds a little bit of work for attackers, but there are so many attacks that 
> can bypass ASLR even with strong entropy that it just increases the work 
> factor slightly.  If you???re running code written in C, then you???re better 
> off relying on Capscium compartmentalisation to limit what the attacker can 
> do once they???ve compromised it.

Kib's ASR implementation hasn't made it to HEAD, yet. It differs from
ASLR in pretty drastic ways. Using heap spraying attacks, an attacker
will easily be able to disable the ASR implementation Kib has proposed.
The same does not hold true for the proper ASLR implementation that has
existed for a number of years--HardenedBSD's. Simply forcing address
space fragmentation should not disable ASLR, which is the case for
FreeBSD's ASR. Kib's implementation requires a lot of further work,
especially in regards to stack and shared page randomization, which
doesn't exist in his patch. He views stack and shared page randomization
outside the scope of ASR and I have no clue why as no explanation has
been given.

While ASLR bypasses exist (ROP, SROP, JROP, etc.), they require a number
of additional vulnerabilities to be able to effectively control [ER]IP.
Just like any security technology, ASLR isn't meant to be the
end-all-be-all of security, but just one more layer in a
defense-in-depth strategy. The more layers an attacker has to punch
through, the higher the burden.

Capsicum would indeed be something to look into, but is heavy-handed and
requires modification of source code. Capsicum cannot be applied to
proprietary applications without coordination from the vendor, whereas
ASLR can be. I like Capsicum, but integrating "ALL THE THINGS!" with it
takes a lot of work.

Thanks,

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: if_iwn dhcp troubles

[Ronald Klop]

Hello Adrian,

See attachments. One is with and one is without -ht option.

# 14:40:52 root@sjakie [~]
uname -a
FreeBSD sjakie.klop.ws 11.0-ALPHA1 FreeBSD 11.0-ALPHA1 #7 r300901M: Sat  
May 28 16:54:00 CEST 2016  
r...@sjakie.klop.ws:/usr/obj/usr/src/sys/GENERIC-NODEBUG  amd64


Regards,
Ronald.



On Tue, 31 May 2016 02:38:38 +0200, Adrian Chadd   
wrote:



hi,

what's the output of 'ifconfig -v wlan0 list scan' ?


-a


On 30 May 2016 at 14:15, Ronald Klop  wrote:
On Mon, 30 May 2016 03:01:10 +0200, Adrian Chadd  


wrote:


ok, so there seem to be more lingering 802.11n issues. can you tell me
mrore about the environment there, so I can try to duplicate it?

I'd like to fix whatever 11n issues there are in iwn!

Thanks!


-a



Hi Adrian,

I don't know what you want to know, but it is just my laptop at home. I
installed an Intel WiFi card, because the Broadcom it had didn't have
support in FreeBSD. I normally have if_lagg configured, but disabled it  
to

debug this.
I connect with WiFi to a Ubiquiti Unifi AP AC Lite
(https://www.ubnt.com/unifi/unifi-ap-ac-lite/).
Other (non-freebsd) devices, like a phone, connect happily with the  
WiFi.



pciconf -vl:
...
iwn0@pci0:4:0:0:class=0x028000 card=0x40608086 chip=0x088e8086
rev=0x24 hdr=0x00
vendor = 'Intel Corporation'
device = 'Centrino Advanced-N 6235'
class  = network
...
=
cat /etc/wpa_supplicant.conf (really plain)
network={
ssid="x"
psk=""
}
=
cat /etc/rc.conf:
# Kernel
zfs_enable="YES"
saver="green"
accounting_enable="YES"
powerd_enable="YES"
devfs_system_ruleset="system"
background_fsck="NO"
dumpdev="AUTO"
kld_list="coretemp ichsmb radeonkms fuse if_lagg vboxdrv cuse"
keymap="/etc/keymap.test"
# if_bwn bwn_v4_lp_ucode"

# Networking
hostname="sjakie.klop.ws"
#wpa_supplicant_flags="$wpa_supplicant_flags -d"
wlans_iwn0="wlan0"
create_args_wlan0="wlanaddr 00:26:b9:12:40:a4 country NL"
ifconfig_wlan0="-ht WPA"
#ifconfig_bge0="up"
#cloned_interfaces="lagg0"
#ifconfig_lagg0="laggproto failover laggport bge0 laggport wlan0  
SYNCDHCP"


ifconfig_wlan0="$ifconfig_wlan0 DHCP"

#ifconfig_DEFAULT="SYNCDHCP"
#ifconfig_em0_alias0="inet 192.168.1.36 netmask 0x"
firewall_enable="YES"
firewall_type="/etc/ipfw.sjakie"
#local_unbound_enable="YES"

# Daemons
ntpdate_enable="YES"
ntpd_enable="YES"
sshd_enable="YES"
inetd_enable="YES"
syslogd_flags=""
sendmail_enable="NO"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"

# Bluetooth
#hcsecd_enable="YES"
#sdpd_enable="YES"
#bthidd_enable="YES"

# Ports
bsdstats_enable="YES"
#postfix_enable="YES"
#smtpd_enable="YES"
#smtpd_flags="-v"
cupsd_enable="YES"
dbus_enable="YES"
polkitd_enable="YES"
#hald_enable="YES"
smartd_enable="YES"
#mdnsd_enable="YES"
avahi_daemon_enable="YES"
bruteblockd_enable="YES"
bruteblockd_table="1"
bruteblockd_flags="-s 5"
#collectd_enable="YES"

rpcbind_enable="YES"
#nfs_client_enable="YES"
mountd_enable="YES"
nfs_server_enable="YES"

panicmail_enable="YES"
slim_enable="YES"

webcamd_enable="YES"
webcamd_flags="-m v4l2-dev.v4l_hflip=1"


=
dmesg:
Copyright (c) 1992-2016 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights  
reserved.

FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-ALPHA1 #7 r300901M: Sat May 28 16:54:00 CEST 2016
r...@sjakie.klop.ws:/usr/obj/usr/src/sys/GENERIC-NODEBUG amd64
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on  
LLVM

3.8.0)
can't re-use a leaf (ixl_rx_miss_bufs)!
VT(vga): resolution 640x480
CPU: Pentium(R) Dual-Core CPU   T4300  @ 2.10GHz (2094.80-MHz  
K8-class

CPU)
  Origin="GenuineIntel"  Id=0x1067a  Family=0x6  Model=0x17  Stepping=10

Features=0xbfebfbff

Features2=0xc00e39d
  AMD Features=0x20100800
  AMD Features2=0x1
  TSC: P-state invariant, performance statistics
real memory  = 4294967296 (4096 MB)
avail memory = 4047171584 (3859 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
random: unblocking device.
ioapic0  irqs 0-23 on motherboard
random: entropy device external interface
kbd1 at kbdmux0
netmap: loaded module
module_register_init: MOD_LOAD (vesa, 0x80fe16e0, 0) error 19
vtvga0:  on motherboard
cryptosoft0:  on motherboard
acpi0:  on motherboard
acpi0: Power Button (fixed)
Timecounter "HPET" frequency 14318180 Hz quality 950
Event timer "HPET" frequency 14318180 Hz quality 450
Event timer "HPET1" frequency 14318180 Hz quality 440
Event timer "HPET2" frequency 

Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

[Marcelo Araujo]

Hey,

Thanks for the CFT Craig.

2016-06-09 14:41 GMT+08:00 Xin Li :

>
>
> On 6/8/16 23:10, Craig Rodrigues wrote:
> > Hi,
> >
> > I have worked with Marcelo Araujo to port OpenBSD's ypldap to FreeBSD
> > current.
> >
> > In latest current, it should be possible to put in /etc/rc.conf:
> >
> > nis_ypldap_enable="YES"
> > to activate the ypldap daemon.
> >
> > When set up properly, it should be possible to log into FreeBSD, and have
> > the backend password database come from an LDAP database such
> > as OpenLDAP
> >
> > There is some documentation for setting this up, but it is OpenBSD
> specific:
> >
> > http://obfuscurity.com/2009/08/OpenBSD-as-an-LDAP-Client
> > http://puffysecurity.com/wiki/ypldap.html#2
> >
> > I did not bother porting the OpenBSD LDAP server to FreeBSD, so that
> > information
> > does not apply.  I figure that openldap from ports should work fine.
> >
> > I was wondering if there is someone out there familiar enough with LDAP
> > and has a setup they can test this stuff out with, provide feedback, and
> > help
> > improve the documentation for FreeBSD?
>
> Looks like it would be a fun weekend project.  I've cc'ed a potential
> person who may be interested in this as well.
>
> But will this worth the effort? (I think the current implementation
> would do everything with plaintext protocol over wire, so while it
> extends life for legacy applications that are still using NIS/YP, it
> doesn't seem to be something that we should recommend end user to use?)
>

I can see two good point to use ypldap that would be basically for users
that needs to migrate from NIS to LDAP or need to make some integration
between legacy(NIS) and LDAP during a transition period to LDAP.

As mentioned, NIS is 'plain text' not safe by its nature, however there are
still lots of people out there using NIS, and ypldap(8) is a good tool to
help these people migrate to a more safe tool like LDAP.


>
> > I would also be interested in hearing from someone who can see if
> > ypldap can work against a Microsoft Active Directory setup?
>
> Cheers,
>
>
All my tests were using OpenLDAP, I used the OpenBSD documentation to setup
everything, and the file share/examples/ypldap/ypldap.conf can be a good
start to anybody that wants to start to work with ypldap(8).

Would be nice hear from other users how was their experience using ypldap
with MS Active Directory and perhaps some HOWTO how they made all the setup
would be amazing to have.

Also, would be useful to know who are still using NIS and what kind of
setup(user case), maybe even the reason why they are still using it.


Best,
-- 

-- 
Marcelo Araujo(__)ara...@freebsd.org
\\\'',)http://www.FreeBSD.org    \/  \ ^
Power To Server. .\. /_)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT: bhyve and Kernel SamePage Mergin

[David Chisnall]

If this paper is the one that I think it is, then I was one of the reviewers.  
Their attack is neat, but it depends quite a lot on being able to 
deterministically trigger deduplication.  Their proof-of-concept exploit was on 
Windows (and JavaScript attack was really fun) and I’m not convinced that it 
would work reliably on Linux or VMWare ESX, which both defer deduplication for 
as long as possible to avoid NUMA-related overheads.

We don’t currently have a FreeBSD implementation, but if someone wanted to 
provide one then a defence against this attack would be fairly simple: count 
the number of CoW faults that a process is receiving and if it reaches a 
certain threshold then remove all of its memory from the set of eligible pages. 
 The attack relies on being able to repeatedly trigger CoW faults and time 
whether they occur, with the same set of pages.  At least some existing 
implementations will make this impossible as these pages will repeatedly be 
deduplicated and then duplicated and this is already a pathological case that 
most memory deduplication implementations need to handle (as well as being a 
security hole, it’s also a big performance killer).

Kib has been working on ASLR for FreeBSD (I think it’s in 11?), but at this 
point it’s more of a checkbox item than a serious mitigation technique.  It 
adds a little bit of work for attackers, but there are so many attacks that can 
bypass ASLR even with strong entropy that it just increases the work factor 
slightly.  If you’re running code written in C, then you’re better off relying 
on Capscium compartmentalisation to limit what the attacker can do once they’ve 
compromised it.

David

> On 8 Jun 2016, at 16:01, O. Hartmann  wrote:
> 
> A couple of days I got as a responsible personell for a couple of systems a 
> warning about
> the vulnerabilities of the mechanism called "Kernel SamePage Mergin". On this 
> year's IEEE
> symposion there has been submitted a paper by Bosman et al., 2016, describing 
> an attack
> on KSM. This technique, also referred to as memory/page deduplication, seems 
> to be
> vulnerable by design under certain circumstances. I guess the experts of the 
> readers here
> do already know, but I consider myself a non-expert and therefore, I'd like 
> to ask about
> the status of that kind of development in FreeBSD. I read about a project of 
> last year's
> Google Summer of Code 2015 targetting KSM on FreeBSD.
> 
> In Linux, this deduplication techniques is implemented since kernel 2.6.38 
> and Windows
> Kernel uses this techniques since Windows 8.1 and sibblings (also Windows 
> Server). We
> were strongly advised to disable those "features" in Windows clients, servers 
> and Linux
> servers, if used.
> 
> Other papers describe successful attacks on memory contents and ASLR by 
> misusing KSM. On
> Windows, mmap() entropy is 19bit, on Linux usually 28bit. And FreeBSD (if
> planned/used/already implemented?)? 
> 
> If you are interested I could provide links or PDFs of the papers I already 
> gathered
> about that subject (it is not much, simply google for "KSM FReeBSD" or KSM 
> deduplication
> ASLR).
> 
> Thanks in advance,
> 
> oh



smime.p7s
Description: S/MIME cryptographic signature

Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

[Xin Li]

On 6/8/16 23:10, Craig Rodrigues wrote:
> Hi,
> 
> I have worked with Marcelo Araujo to port OpenBSD's ypldap to FreeBSD
> current.
> 
> In latest current, it should be possible to put in /etc/rc.conf:
> 
> nis_ypldap_enable="YES"
> to activate the ypldap daemon.
> 
> When set up properly, it should be possible to log into FreeBSD, and have
> the backend password database come from an LDAP database such
> as OpenLDAP
> 
> There is some documentation for setting this up, but it is OpenBSD specific:
> 
> http://obfuscurity.com/2009/08/OpenBSD-as-an-LDAP-Client
> http://puffysecurity.com/wiki/ypldap.html#2
> 
> I did not bother porting the OpenBSD LDAP server to FreeBSD, so that
> information
> does not apply.  I figure that openldap from ports should work fine.
> 
> I was wondering if there is someone out there familiar enough with LDAP
> and has a setup they can test this stuff out with, provide feedback, and
> help
> improve the documentation for FreeBSD?

Looks like it would be a fun weekend project.  I've cc'ed a potential
person who may be interested in this as well.

But will this worth the effort? (I think the current implementation
would do everything with plaintext protocol over wire, so while it
extends life for legacy applications that are still using NIS/YP, it
doesn't seem to be something that we should recommend end user to use?)

> I would also be interested in hearing from someone who can see if
> ypldap can work against a Microsoft Active Directory setup?

Cheers,



signature.asc
Description: OpenPGP digital signature

[CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

[Craig Rodrigues]

Hi,

I have worked with Marcelo Araujo to port OpenBSD's ypldap to FreeBSD
current.

In latest current, it should be possible to put in /etc/rc.conf:

nis_ypldap_enable="YES"
to activate the ypldap daemon.

When set up properly, it should be possible to log into FreeBSD, and have
the backend password database come from an LDAP database such
as OpenLDAP

There is some documentation for setting this up, but it is OpenBSD specific:

http://obfuscurity.com/2009/08/OpenBSD-as-an-LDAP-Client
http://puffysecurity.com/wiki/ypldap.html#2

I did not bother porting the OpenBSD LDAP server to FreeBSD, so that
information
does not apply.  I figure that openldap from ports should work fine.

I was wondering if there is someone out there familiar enough with LDAP
and has a setup they can test this stuff out with, provide feedback, and
help
improve the documentation for FreeBSD?

I would also be interested in hearing from someone who can see if
ypldap can work against a Microsoft Active Directory setup?

Thanks.
--
Craig
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"