Re: What is this Very Stupid DOS Attack Script?

[Mike Tancsa]

At 11:49 AM 06/04/2005, Martin McCormick wrote:
We have been noticing flurries of sshd reject messages in
which some system out there in the hinterlands hits us with a flood of
ssh login attempts.  An example:
Apr  6 05:41:51 dc sshd[88763]: Did not receive identification
string from 67.19.58.170
Apr  6 05:49:42 dc sshd[12389]: input_userauth_request: illegal
user anonymous
Other than spewing lots of entries in to syslog, what is the
purpose of the attack?  Are they just hoping to luck in to an open
account?  The odds of guessing the right account name and then guessing
the correct password are astronomical to say the least.

Actually, sadly the odds are far too good given the cost to run such a 
script.  Unless you force users to use GOOD passwords, they will use dumb 
ones Think Paris Hilton recently.  The cost to let a script like that 
go in the background and pound away at hosts that have open ssh access is 
zilch. If you have ftpd running anywhere, you will see similar attempts

---Mike 

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: IPSEC l2tpd and Windows shares problem

[Mike Tancsa]

At 04:32 AM 17/04/2005, Vicky Shrestha wrote:
Dear all,
I am running IPSEC and l2tpd in FreeBSD 4.9.
mtu 1400
mru 1400

It sounds like you have the PMTU issue covered, but it also sounds like an 
MTU issue.  Can you try and generate some large ping packets and see if 
they are being fragmented properly ?  hping is useful for this as you can 
toggle the DF bit as well as send non ICMP type packets.

Also, are the IPSEC polices all installed properly ?
---Mike 

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Fwd: (KAME-snap 9012) racoon in the kame project

[Mike Tancsa]

FYI, looks like support for Racoon is ending.  Does anyone have any 
experience with the version in ipsec-tools ?

---Mike

Racoon users,
This is the announcement that the kame project will quit providing
a key management daemon, the racoon, and that "ipsec-tools" will become
the formal team to release the racoon.
The final release of the racoon in the kame project will be on 4/25.
Because there were some problem for users currently,
- I did not add new feature.
- I intent to fix security holes and apply patches.
  however, it could not be enough done.
- I could not reply your questions, bug reports and
  useful suggestions.
I was sorry that it was not enough support for users.  I was thinking
that I would not want to make trouble for users anymore.
There is another racoon as known as "ipsec-tools" in the sourceforge.
It is being developed very actively, is stable than racoon and
implemented radical feature.  But it is sometime trouble for users
that double racoons are released.  It is also wasteful that development
resource is devided.  I was thinking that two racoon could be merged.
There was an oppotunity having a meeting with some of "ipsec-tools"
developers at the IETF 62th in Minneapolis.  I told my thought to
the developers.  They willingly agreed with my proposal.
They told me that they could become the formal support team.  So the kame
project decided to quit providing, and supporting racoon.
If you are interesting in the "ipsec-tools", please visit thier web page,
http://ipsec-tools.sourceforge.net/
and subscribe to the mailing list by yourself.
http://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel
Thank you up to now, and best regards,
P.S.
Some people interested in "racoon2".  It is still pre-alpha version,
not satisfied with users.  I will concentrate developping "racoon2"
to be stable.  It needs more than one year at least.
//Shoichi Sakane
----
Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,[EMAIL PROTECTED]
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: HOW TO Enable IPSec for FreeBSD.......???

[Mike Tancsa]

At 09:45 AM 17/05/2005, mohan chandra wrote:
Hi,
 I have tried to enable IPSec support for my
FreeBSD( 4.11-RELEASE) system.
Hi,
You need to reboot after installing the new kernel.
---Mike 

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Repeated attacks via SSH

[Mike Tancsa]

At 06:08 PM 02/10/2005, Don Lewis wrote:

> practical, everyone limit SSH logins to the minimum possible number
> of users via the "AllowUsers" directive. We also have a log monitor
> that watches the logs (/var/log/auth.log in particular) and
> blackholes hosts that seem to be trying to break in via SSH.

It's also a good idea to only allow public key authentication from
remote hosts.  This avoids the risks of password guessing and password
capture by shoulder surfers or key loggers.


Couple of other things to add,

deny all access via hosts.allow and only let in those who are 
supposed to come in


launch sshd from inetd and then use the rate limiting feature of 
inetd (e.g. -C 10) to reject hosts with more than 10 connections 
attempts from a single IP per minute


Move to a different port than the default 22 to avoid scanners

use "port knocking" to dynamically allow a remote host to see port 22 
(/usr/ports/security/doorman)


Also saw someone post on the openbsd list to use pf to rate limit 
(http://groups.google.ca/group/lucky.openbsd.misc/tree/browse_frm/thread/86320212088ec09/42313fa39522f2b7?rnum=1&hl=en&q=openbsd+ssh+crackers+pf+table+ssh&_done=%2Fgroup%2Flucky.openbsd.misc%2Fbrowse_frm%2Fthread%2F86320212088ec09%2F605665a2b79f493b%3Flnk%3Dst%26q%3Dopenbsd+ssh+crackers+pf+table+ssh%26rnum%3D1%26hl%3Den%26#doc_605665a2b79f493b)




table  persist file "/etc/tables/crackers"
block in quick from 
pass in on $ext_if inet proto tcp from any to ($ext_if) \
   port $tcp_services flags S/SA modulate state \
(max-src-conn 5, max-src-conn-rate 4/60, overload  flush global)

crontab:

0****   pfctl -t crackers -Tsh > /etc/tables/crackers
--

---Mike 


___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD Security Advisory FreeBSD-SA-05:21.openssl

[Mike Tancsa]

At 10:13 AM 12/10/2005, Ivan Voras wrote:

Tobias Roth wrote:

On Wed, Oct 12, 2005 at 12:09:53PM +0200, jere wrote:



And you cannot expect the port maintainers
to backport security fixes if the upstream provider chose to release the
fix only together with a new version.


Yes you can, ask these guys: http://www.debian.org/. It's just a 
matter of policy.


I dislike the long cycles between version updates in Debian but must 
admit that the "stable" distributions indeed justify their name, 
INCLUDING packages.


My idea is that there could maybe be some "core" ports, about 1500 or so,


This sounds like a recipe for confusion.  Some users have problems 
distinguishing between whats in the base, and whats out of the 
ports.  Another type of "psudo base app" would just add to the 
confusion.  Users / admins need to take *some* responsibility for 
what is installed on their system.  Many ports are not very well 
maintained in the first place and to say that the security team 
should be responsible for another 1500 applications is not realistic.


---Mike 


___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Running nessus on freebsd...

[Mike Tancsa]

At 06:21 PM 09/02/2006, Garance A Drosihn wrote:


Are other people here running nessus (2.2.6) with the "registered
plugins"?  (not the commercial registration).


Hi,
I am running the same sort of setup, with registered plugins 
but with the X-client.  Typically, I shut down the daemon, run the 
nessus-update-plugins, start the daemon up again, run "nessus" which 
opens up an X app on my workstation and then login and away it 
goes.  Does it work for you if you do it via X ?


[verify1]% nessus -v
nessus (Nessus) 2.2.6 for FreeBSD

(C) 1998 - 2003 Renaud Deraison <[EMAIL PROTECTED]>
SSL used for client - server communication

[verify1]%

---Mike 


___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD Security Advisory FreeBSD-SA-06:13.sendmail

[Mike Tancsa]

Hi,
The patches apply cleanly on RELENG_4, but sendmail does not 
compile properly using

 ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-06:13/sendmail411.patch


# cd /usr/src/usr.sbin/sendmail
# make obj && make depend && make && make install
rm -f .depend
mkdep -f .depend 
-a-I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src 
-I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/include -I. 
-DNEWDB -DNIS -DMILTER -DTCPWRAPPERS -DMAP_REGEX -DDNSMAP -DNETINET6 
-DSTARTTLS -D_FFR_TLS_1 
-D_FFR_DEAL_WITH_ERROR_SSL 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/alias.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/arpadate.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/bf.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/collect.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/conf.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/control.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/convtime.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/daemon.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/deliver.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/domain.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/envelope.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/err.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/headers.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/macro.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/main.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/map.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/mci.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/milter.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/mime.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/parseaddr.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/queue.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/ratectrl.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/readcf.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/recipient.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/savemail.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/sasl.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/sfsasl.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/shmticklib.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/sm_resolve.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/srvrsmtp.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/stab.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/stats.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/sysexits.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/timers.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/tls.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/trace.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/udb.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/usersmtp.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/util.c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/version.c
echo sendmail: /usr/lib/libc.a /usr/lib/libutil.a /usr/lib/libwrap.a 
/usr/obj/usr/src/usr.sbin/sendmail/../../lib/libsmutil/libsmutil.a 
/usr/obj/usr/src/usr.sbin/sendmail/../../lib/libsm/libsm.a 
/usr/lib/libssl.a /usr/lib/libcrypto.a  >> .depend
cc -O -pipe -march=pentiumpro 
-I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src 
-I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/include -I. 
-DNEWDB -DNIS -DMILTER -DTCPWRAPPERS -DMAP_REGEX -DDNSMAP -DNETINET6 
-DSTARTTLS -D_FFR_TLS_1 -D_FFR_DEAL_WITH_ERROR_SSL -c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/alias.c
cc -O -pipe -march=pentiumpro 
-I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src 
-I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/include -I. 
-DNEWDB -DNIS -DMILTER -DTCPWRAPPERS -DMAP_REGEX -DDNSMAP -DNETINET6 
-DSTARTTLS -D_FFR_TLS_1 -D_FFR_DEAL_WITH_ERROR_SSL -c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/arpadate.c
cc -O -pipe -march=pentiumpro 
-I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src 
-I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/include -I. 
-DNEWDB -DNIS -DMILTER -DTCPWRAPPERS -DMAP_REGEX -DDNSMAP -DNETINET6 
-DSTARTTLS -D_FFR_TLS_1 -D_FFR_DEAL_WITH_ERROR_SSL -c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/bf.c
cc -O -pipe -march=pentiumpro 
-I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src 
-I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/include -I. 
-DNEWDB -DNIS -DMILTER -DTCPWRAPPERS -DMAP_REGEX -DDNSMAP -DNETINET6 
-DSTARTTLS -D_FFR_TLS_1 -D_FFR_DEAL_WITH_ERROR_SSL -c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/collect.c
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/collect.c: In 
function `collecttimeout':
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/collect.c:941: 
`CollectProgress' undeclared (first use in this function)
/usr/src/usr.sbin/sendmail/../../contrib/sendmai

Re: FreeBSD Security Advisory FreeBSD-SA-06:13.sendmail

[Mike Tancsa]

At 08:57 AM 23/03/2006, Oleg Khomichenko wrote:

=
> Announced:  2006-03-22
> Affects:All FreeBSD releases.


15:33 [EMAIL PROTECTED]:/usr/src>uname -a
FreeBSD .xxx.xx 4.11-STABLE FreeBSD 4.11-STABLE #1: Mon
Apr 11 18:42:41 EEST 2005
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/ALFA  i386


For RELENG_4, I used the same patch that is used on RELENG_5 and RELENG_6. ie

ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-06:13/sendmail.patch

and it seems to apply cleanly and work.

---Mike 


___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Crypto hw acceleration for openssl

[Mike Tancsa]

At 10:27 AM 24/04/2006, Pawel Jakub Dawidek wrote:

On Sun, Apr 23, 2006 at 09:16:13PM +0200, Oliver Fromme wrote:
+> Winston Tsai <[EMAIL PROTECTED]> wrote:
+>  > I got roughly the same performance results when I use the openssl speed
+>  > test with and without a hifn 7956 cryto card
+>  > [...]
+>  > Then I ran:
+>  > Openssl speed des-cbc
+>  > [...]
+>  > My understanding is that openssl will detect the presence of an
+>  > accelerator card and use it (via \dev\crypto) instead of the crypto
+>  > library.
+>  > Did I miss something here?
+>
+> I don't know if the openssl speed test picks up the crypto-
+> dev hardware automatically.  But ssh/scp definitely does.
+>
+> I have run several tests on my VIA C3 Nehemiah+RNG+ACE,
+> which accelerates AES encryption.  When the padlock(4)
+> module is loaded (it contains the Nehemiah ACE support),
+> ssh/scp performance is roughly doubled.  It's quite
+> noticeable when transfering large files.
+>
+> Best regards
+>Oliver
+>
+> PS:  I can provide some benchmark numbers if interested.

The problem is that OpenSSL don't know how to accelerate AES192 and
AES256 with cryptodev. The patch which fix this is available here:

http://people.freebsd.org/~pjd/patches/hw_cryptodev.c.patch

PS. For AES128 cryptodev can be used without the patch.



If you use the padlock engine, you will also need the patch discussed in

http://cvs.openssl.org/chngview?cn=13061

http://sourceforge.net/mailarchive/message.php?msg_id=11419213


Without it, apps like openvpn will running into periodic crypto errors.

---Mike


begin 644 patch
M+2TM(&5N9U]P861L;V-K+F,),C`P-2\P-"\P-"[EMAIL PROTECTED]"BLK
M*R!E;F=?<&%D;&]C:RYC"3(P,#4O,#0O,30@,#'0L96-X"B`)"7T*('T*"@``
`
end

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Integrity checking NANOBSD images

[Mike Tancsa]

We have a number of Soekris devices that we will be deploying 
remotely in semi- hostile physical environments.   The remote links 
are dialup so I dont have a lot of bandwidth available.  I want to do 
integrity checks of the images so that I can detect any tampering of 
the flash image.


If I upload a static sha256 binary to /tmp on the remote box (which 
is a RAM disk) and then do something like


e.g.
# ssh remote1.example.com "mkdir /tmp/rand-directory"
# scp /usr/local/bin/sha256 remote1.example.com:/tmp/rand-directory/sha256
# scp /usr/local/bin/dd remote1.example.com:/tmp/rand-directory/dd

# ssh remote1.example.com "/tmp/rand-directory/dd if=/dev/ad2s1a 
bs=4096k | /tmp/rand-directory/sha256"

120+1 records in
120+1 records out
505389056 bytes transferred in 169.727727 secs (2977646 bytes/sec)
955ebad583bfc0718eb28ac89563941407294d5c61a0c0f35e3773f029cc0685

Can I be reasonably certain the image has not been tampered with 
?  Or are there trivial ways to defeat this check ?


The flash is always mounted read-only, so in theory nothing should 
change with it.  Or do I need to cram on tripwire or similar programs 
onto the nanobsd image ?


---Mike



----
Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,[EMAIL PROTECTED]
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Integrity checking NANOBSD images

[Mike Tancsa]

At 04:05 PM 11/07/2006, Poul-Henning Kamp wrote:

In message <[EMAIL PROTECTED]>, Chuck Swiger writes:

>Checksumming the device image is a fine way of checking the 
integrity of it,
>assuming it is read-only.  The only thing you might want to do is 
use two or
>three checksum algorithms (ie, use sha256 and md5 and something 
else), so that

>someone can't create a new image which matches the sha256 checksum of the
>original.

A much better idea is to send a random "salt" to be prepended to
the disk image before it is run through sha256, that would prevent
the attacker from running sha256 and any other algorithm you
could care for on the image, store the results and return them
with trojans.

Copying the sha256 binary over is no guarantee against a kernel
embedded trojan.

But then again, how paranoid one has to be is a matter of preference.



Hi,
Thanks for the responses.  I know there are no perfect ways. 
I guess I want to understand the risk as much as possible and 
mitigate against tampering as much as possible without designing the 
requirement for some guy to sit in front of the box with a gun :)


With respect to prepending a random salt to the image, can you expand 
what you mean ?


---Mike



--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Integrity checking NANOBSD images

[Mike Tancsa]

At 04:34 PM 11/07/2006, Ruslan Ermilov wrote:

> >
> With respect to prepending a random salt to the image, can you expand
> what you mean ?
>
It means that every time you want to checksum it, you send some
random bits to be prepended to the image, then compute the
checksum(s).  You then do the same (with the same salt) on a
trusted host and compare the results.


OK, but that implies I have a copy of the image locally.  We do on 
occasion make modifications to the config in the field, and sending 
back a 512MB image over dialup would be difficult for this deployment.


---Mike 


___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Integrity checking NANOBSD images

[Mike Tancsa]

At 04:45 PM 11/07/2006, R. B. Riddick wrote:

--- Poul-Henning Kamp <[EMAIL PROTECTED]> wrote:
> Arming a trojan to just do 'sleep 145 ; echo "sha256 = 0248482..."'
> when you thing you're running sha256 would be trivia.
>
But what if the trojan copies its files to the RAM disc and waits for this
sha256 binary showing up? And then, when it is there, it removes its 
changes on

the hard disc  (those changes certainly must be in unused (formerly zeroed)
areas of the hard disc or in the (zeroed) end of certain shell 
scripts... Or do

I miss something?



Yes, sounds possible.  Between checks, "undo" the trojan.  However, 
the binary would have to live somewhere on the flash or it would not 
survive reboots and you would have to tinker with the bootup process 
to load the trojan at boot time.





Wasn't is usual some years ago to switch the boot disc hardware to "read only"
mode? I dont know how to do that, but my source seemed to be trustworthy
(although I never saw him - I just heard his voice...)... ;-))

A switch like on those 1.44'' floppy discs would be good...
But then software/OS updates would require physical access to the box...


For this app, the problem is that there might indeed be physical 
tampering with the box despite some reasonable efforts to lock it up. 


___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

http://www.openssl.org/news/secadv_20060905.txt

[Mike Tancsa]

Does anyone know the practicality of this attack ? i.e. is this trivial to do ?

---Mike


Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,[EMAIL PROTECTED]
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: http://www.openssl.org/news/secadv_20060905.txt

[Mike Tancsa]

At 10:53 AM 9/5/2006, Mike Tancsa wrote:
Does anyone know the practicality of this attack ? i.e. is this 
trivial to do ?


Also, for RELENG_6, can someone confirm the patch referenced in

http://www.openssl.org/news/patch-CVE-2006-4339.txt

be applied with the one change of


+{ERR_REASON(RSA_R_PKCS1_PADDING_TOO_SHORT),"pkcs1 padding too short"},

to


+{RSA_R_PKCS1_PADDING_TOO_SHORT,"pkcs1 padding too short"},


I manually added in the diffs and everything seems to compile and 
function with some limited testing. I did


cd /usr/src/crypton/openssl/crypto/rsa
patch < p
cd /usr/src/secure
make clean
make obj
make depend
make includes
make
make install






---Mike

--------
Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,[EMAIL PROTECTED]
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


p
Description: Binary data
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

OpenSSH DoS issue ?

[Mike Tancsa]

Is the version in FreeBSD vulnerable ?

http://www.openssh.com/txt/release-4.4

I know version 1 is disabled by default, but if its not, does it 
impact the daemon ?


---Mike


Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,[EMAIL PROTECTED]
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: OpenSSL bufffer overflow

[Mike Tancsa]

At 05:43 PM 9/28/2007, Stefan Esser wrote:

I did not see any commits to the OpenSSL code, recently; is anybody
going to commit the fix?

See http://www.securityfocus.com/archive/1/480855/30/0 for details ...


How serious is this particular issue ? Is it easily exploitable, or 
difficult to do ?  Are some apps more at risk of exploitation than 
others ? e.g. ssh,apache ?


---Mike



Regards, STefan
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: OpenSSL bufffer overflow

[Mike Tancsa]

At 12:05 PM 10/5/2007, Simon L. Nielsen wrote:

On 2007.10.03 19:49:31 -0400, Mike Tancsa wrote:
> At 05:43 PM 9/28/2007, Stefan Esser wrote:
>> I did not see any commits to the OpenSSL code, recently; is anybody
>> going to commit the fix?
>>
>> See http://www.securityfocus.com/archive/1/480855/30/0 for details ...
>
> How serious is this particular issue ? Is it easily exploitable, or
> difficult to do ?  Are some apps more at risk of exploitation 
than others ?

> e.g. ssh,apache ?

(/me kicks mutt again for not showing new mails in mailboxes...)

Anyway, I don't think it's very likely many people are affected by
this since not many programs call SSL_get_shared_ciphers().  No
application in the base system calls SSL_get_shared_ciphers acording
to grep, other than openssl(1)'s built in ssl client/server.

I also did a quick grep in apache 2.2 (I think it was 2.2) and it
didn't reference the function either, but this was a quick check so if
it matters to anyone, check yourself.


Thanks!  I did the same grep, but wasnt sure whether or not that 
particular function (SSL_get_shared_ciphers) got called by another 
function in OpenSSL which was originally called by some of the big 
apps like sendmail,apache and sshd


---Mike 


___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

testing wireless security

[Mike Tancsa]

I have been playing around with 3 ath based FreeBSD boxes and seem to 
have got everything going via WPA and a common PSK for 802.11x 
auth.  However, I want to have a bit more certainty about things 
working properly.


What tools do people recommend for sniffing and checking a wireless network ?

In terms of IDS, is there any way to see if people are trying to 
bruteforce the network ?  I see hostap has nice logging, but anything 
beyond that ?


e.g. with a bad psk on the client
 hostapd: ath0: STA 00:0b:6b:2b:bb:69 IEEE 802.1X: unauthorizing port

is there a way to black list MAC addresses, or just allow certain 
ones from even trying ?  IPSEC will be running on top, but I still 
want a decent level of security on the transport layer.



On the client I have

% cat /etc/wpa_supplicant.conf
network={
  ssid="testnet1"
  #
  psk="xxx"
}


% ifconfig ath0
ath0: flags=8843 mtu 1500
inet 2.2.2.9 netmask 0xff00 broadcast 2.2.2.255
ether 00:0b:6b:2b:bb:69
media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/48Mbps)
status: associated
ssid mike1 channel 1 bssid 00:0b:6b:84:3e:76
authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit TKIP 3:128-bit
txpowmax 49 bmiss 7 protmode CTS burst roaming MANUAL bintval 100


and the host

% ifconfig ath0
ath0: flags=8843 mtu 2290
inet 2.2.2.1 netmask 0xff00 broadcast 2.2.2.255
ether 00:0b:6b:84:3e:76
media: IEEE 802.11 Wireless Ethernet autoselect mode 11g 
status: associated
ssid mike1 channel 1 bssid 00:0b:6b:84:3e:76
authmode WPA privacy MIXED deftxkey 2 TKIP 2:128-bit TKIP 3:128-bit
txpowmax 39 bmiss 7 protmode CTS burst dtimperiod 1 bintval 100


% cat /etc/hostapd.conf
interface=ath0
driver=bsd
logger_syslog=-1
logger_syslog_level=0
logger_stdout=-1
logger_stdout_level=0
debug=3
dump_file=/tmp/hostapd.dump
ctrl_interface=/var/run/hostapd
ctrl_interface_group=wheel
ssid=testnet1
macaddr_acl=0
auth_algs=1
 IEEE 802.1X related config 
ieee8021x=0
 WPA/IEEE 802.11i config #
wpa=1
wpa_passphrase=xxx
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP TKIP


---Mike



----
Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,[EMAIL PROTECTED]
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD Security Advisory FreeBSD-SA-08:02.libc

[Mike Tancsa]

At 06:09 PM 1/14/2008, FreeBSD Security Advisories wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

=
FreeBSD-SA-08:02.libc   Security Advisory
  The FreeBSD Project

Topic:  inet_network() buffer overflow

For programs which passes untrusted data to inet_network(), an
attacker may be able to overwrite a region of memory with user defined
data by causing specially crafted input to be passed to
inet_network().


For the "usual suspects" of applications running, (e.g. sendmail, 
apache, BIND etc) would it be possible to pass crafted packets 
through to this function remotely via those apps ?  ie how easy is this to do ?


---Mike 


___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD Security Advisory FreeBSD-SA-08:02.libc

[Mike Tancsa]

At 12:22 AM 1/15/2008, Mark Andrews wrote:

>
> For the "usual suspects" of applications running, (e.g. sendmail,
> apache, BIND etc) would it be possible to pass crafted packets
> through to this function remotely via those apps ?  ie how easy 
is this to do

>  ?

The usual suspects don't call inet_network().
route calls inet_network() but not routed doesn't.


Thanks to all who responded so far!  I had a look at some of the 
ports I am using and so far all I found was


 find . -name "*.c" | xargs grep inet_network
./apache13-modssl/work/apache_1.3.33/src/modules/proxy/proxy_util.c: 
if (host[i] == '\0' && (ap_inet_addr(host) == -1 || inet_network(host) == -1))


---Mike 


___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: How to take down a system to the point of requiring a newfs with one line of C (userland)

[Mike Tancsa]

At 11:24 PM 2/17/2008, Jim Bryant wrote:

One line summary:
   Too many files in a top-level UFS-2 filesystem directory will 
cause a panic on mount.

How to repeat the problem:
   Compile and run the following as instructed:

umount that filesystem.


Hi,

I tried this on RELENG_7 and RELENG_6 and was not able to panic the box

0[releng7]# ls -l | wc
   20098  200972 1377211
0[releng7]# df -i
Filesystem  1K-blocks UsedAvail Capacity iused   ifree 
%iused  Mounted on

/dev/ad6s1a   1012974   284464   64747431%3308  1380022%   /
devfs   110   100%   0   0  100%   /dev
/dev/ad6s1d   5077038  1221890  344898626%   20243  6392113%   /tmp
/dev/ad6s1e  25385516 15683412  767126467%  370099 2927179   11%   /usr
/dev/ad6s1f  40139596   847342 36081088 2%1001 52039890%   /var
0[releng7]#

and releng_6
0[nanobsd]# ./a.out /tmp/k
0[nanobsd]# ./a.out /tmp/kl
0[nanobsd]# ls -l /tmp/ | wc
   20248  182229 1327842
0[nanobsd]# df -i
Filesystem1K-blocks UsedAvail Capacity iused   ifree 
%iused  Mounted on

/dev/twed0s1a   1012974   109076   82286212%2099  1392111%   /
devfs 110   100%   0   0  100%   /dev
/dev/twed0s1d   4058062  3264732   46868687%   23045  5186494%   /tmp
/dev/twed0s1f  82042376 57488474 1799051276% 2014718 8607232   19%   /usr
/dev/twed0s1e  20308398  5173252 1351047628%1813 26360090%   /var
0[nanobsd]#

After running the program and creating all the files, I just did a 
reboot and all worked just fine post reboot.


Did you fill up the partition or run out of inodes perhaps ?

---Mike 


___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: BIND update?

[Mike Tancsa]

At 06:54 AM 7/9/2008, Oliver Fromme wrote:

Andrew Storms wrote:
 > http://www.isc.org/index.pl?/sw/bind/bind-security.php

I'm just wondering ...

ISC's patches cause source ports to be randomized, thus
making it more difficult to spoof response packets.

But doesn't FreeBSD already randomize source ports by
default?  So, do FreeBSD systems require to be patched
at all?


It doesnt seem to do a very good job of it with 
bind for some reason... Perhaps because it picks a port and reuses it ?


  Doing the following

% cat s
host 1iatest.yahoo.com
host 1iatest2.yahoo.co.uk
host 1iatest3.yahoo.com
host 1iatest4.yahoo.com
host 1iatest4.yahoo.com

shows the same source port being used




08:05:44.269507 IP 64.7.134.1.51761 > 
203.84.197.239.53: 814% [1au] A? 1iatest.yahoo.com. (46)
08:05:44.595674 IP 203.84.197.239.53 > 
64.7.134.1.51761: 814 NXDomain*- 0/1/1 (107)
08:05:44.596251 IP 64.7.134.1.51761 > 
199.212.134.1.53: 38272% [1au] A? 1iatest.yahoo.com.sentex.ca. (56)
08:05:44.649672 IP 199.212.134.1.53 > 
64.7.134.1.51761: 38272 NXDomain* 0/1/1 (116)
08:05:44.65 IP 64.7.134.1.51761 > 
68.142.196.63.53: 20277% [1au] A? 1iatest2.yahoo.co.uk. (49)
08:05:44.743687 IP 68.142.196.63.53 > 
64.7.134.1.51761: 20277*- 1/13/1 CNAME[|domain]
08:05:44.749325 IP 64.7.134.1.51761 > 
68.142.255.16.53: 32407% [1au] A? 1iatest3.yahoo.com. (47)
08:05:44.825666 IP 68.142.255.16.53 > 
64.7.134.1.51761: 32407 NXDomain*- 0/1/1 (108)
08:05:44.826291 IP 64.7.134.1.51761 > 
199.212.134.2.53: 59918% [1au] A? 1iatest3.yahoo.com.sentex.ca. (57)
08:05:44.881667 IP 199.212.134.2.53 > 
64.7.134.1.51761: 59918 NXDomain* 0/1/1 (117)
08:05:44.886352 IP 64.7.134.1.51761 > 
217.12.4.104.53: 56112% [1au] A? 1iatest4.yahoo.com. (47)
08:05:45.021655 IP 217.12.4.104.53 > 
64.7.134.1.51761: 56112 NXDomain*- 0/1/1 (108)
08:05:45.022213 IP 64.7.134.1.51761 > 
64.7.153.49.53: 14304% [1au] A? 1iatest4.yahoo.com.sentex.ca. (57)
08:05:45.075656 IP 64.7.153.49.53 > 
64.7.134.1.51761: 14304 NXDomain* 0/1/1 (117)


and a few min later with new requests,

# tcpdump -ni tun0 port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type NULL (BSD loopback), capture size 96 bytes
08:08:00.273502 IP 64.7.134.1.51761 > 
68.142.255.16.53: 37470% [1au] A? 21iatest.yahoo.com. (47)
08:08:00.350026 IP 68.142.255.16.53 > 
64.7.134.1.51761: 37470 NXDomain*- 0/1/1 (108)
08:08:00.350565 IP 64.7.134.1.51761 > 
199.212.134.1.53: 31976% [1au] A? 21iatest.yahoo.com.sentex.ca. (57)
08:08:00.406013 IP 199.212.134.1.53 > 
64.7.134.1.51761: 31976 NXDomain* 0/1/1 (117)
08:08:00.410993 IP 64.7.134.1.51761 > 
68.142.196.63.53: 2704% [1au] A? 21iatest2.yahoo.co.uk. (50)
08:08:00.500032 IP 68.142.196.63.53 > 
64.7.134.1.51761: 2704*- 1/13/1 CNAME[|domain]
08:08:00.505356 IP 64.7.134.1.51761 > 
68.142.255.16.53: 33992% [1au] A? 21iatest3.yahoo.com. (48)
08:08:00.582006 IP 68.142.255.16.53 > 
64.7.134.1.51761: 33992 NXDomain*- 0/1/1 (109)
08:08:00.582565 IP 64.7.134.1.51761 > 
199.212.134.2.53: 18776% [1au] A? 21iatest3.yahoo.com.sentex.ca. (58)
08:08:00.638004 IP 199.212.134.2.53 > 
64.7.134.1.51761: 18776 NXDomain* 0/1/1 (118)
08:08:00.642684 IP 64.7.134.1.51761 > 
68.142.255.16.53: 54964% [1au] A? 21iatest4.yahoo.com. (48)
08:08:00.72 IP 68.142.255.16.53 > 
64.7.134.1.51761: 54964 NXDomain*- 0/1/1 (109)
08:08:00.720529 IP 64.7.134.1.51761 > 
64.7.153.49.53: 11657% [1au] A? 21iatest4.yahoo.com.sentex.ca. (58)
08:08:00.773998 IP 64.7.153.49.53 > 
64.7.134.1.51761: 11657 NXDomain* 0/1/1 (118)



# sysctl -a net.inet.ip.portrange
net.inet.ip.portrange.randomtime: 45
net.inet.ip.portrange.randomcps: 10
net.inet.ip.portrange.randomized: 1
net.inet.ip.portrange.reservedlow: 0
net.inet.ip.portrange.reservedhigh: 1023
net.inet.ip.portrange.hilast: 65535
net.inet.ip.portrange.hifirst: 49152
net.inet.ip.portrange.last: 65535
net.inet.ip.portrange.first: 49152
net.inet.ip.portrange.lowlast: 600
net.inet.ip.portrange.lowfirst: 1023


---Mike



Best regards
   Oliver

PS:
$ sysctl net.inet.ip.portrange.randomized
net.inet.ip.portrange.randomized: 1
$ sysctl -d net.inet.ip.portrange.randomized
net.inet.ip.portrange.randomized: Enable random port allocation

--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

It's trivial to make fun of Microsoft products,
but it takes a real man to make them work,
and a God to make them do anything useful.
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


___
freebsd-security@freebsd.or

Re: machine hangs on occasion - correlated with ssh break-in attempts

[Mike Tancsa]

At 04:37 PM 8/21/2008, Brooks Davis wrote:

On Thu, Aug 21, 2008 at 10:10:42PM +0200, Rink Springer wrote:
> On Thu, Aug 21, 2008 at 01:03:09PM -0700, Jeremy Chadwick wrote:
> > Finally, consider moving to pf instead, if you really feel ipfw is
> > what's causing your machine to crash.  You might be pleasantly surprised
> > by the syntax, and overall administrative usability (it is significantly
> > superior to ipfw, IMHO).
>
> In fact, pf can already do this out-of-the-box, by doing something like:
>
> table  persist
> pass quick on $wan_if proto tcp from any to any port ssh flags S/SA keep
> state \
>  (max-src-conn 15, max-src-conn-rate 5/3, overload  flush
> global)
>
> If that is not an option, I have found that security/denyhosts works
> pretty well too (it just adds IP's to /etc/hosts.deniedssh, and
> host_access(5) denies them based on this)

You almost certainly don't want to rate limit ssh connections, only failed
ones.  If you rate limit connections and use svn, you're likely to lock your
self out.


I find a happy balance is to exclude trusted CIDR blocks from the 
rate limiting and let everything else be limited.


e.g.


table  persist
table  {192.168.0.0/16,1.0.0.0/24}


block log quick proto tcp from  to any port 22


block  in log on $ext_if all

pass log quick proto { tcp } from {!} to $myaddress port ssh \
flags S/SA keep state \
(max-src-conn 6, max-src-conn-rate 3/30, \
overload  flush global)

pass in on $ext_if inet proto tcp from  to $ext_if port 
ssh keep state


and then a crontab entry

*/5 * * * * /usr/local/sbin/expiretable -v  -t 5m bruteforce

---Mike 


___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Heimdal or MIT for kerberos?

[Mike Tancsa]

We are looking at deploying Kerberos for better user management (SSO) 
and 2 factor authentication via pkcs#11 etokens.  The servers are all 
FreeBSD and the machines principals will login from a mix of FreeBSD, 
Windows and MAC OSX using ssh and openvpn.  As part of our compliance 
project, access must be 2 factor.  The Heimdal in RELENG_7 is a 
rather old version and doesnt seem to have all the bits needed for 
x509 pre-auth so I would probably need to install from the ports 
anyways.   Does anyone have any suggestions as to which 
implementation to use ? We are in Canada so it doesnt matter 
regulation wise. Is one better maintained than the other ?  There are 
no legacy v4 apps

Thanks,

---Mike


Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,[EMAIL PROTECTED]
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Heimdal or MIT for kerberos?

[Mike Tancsa]

At 02:34 AM 9/10/2008, Gunnar Flygt wrote:

I'm very pleased with heimdal 1.1. I compile it from sources. No big
problem. Compile on one machine and copy the file structure to the other
at the same OS level. Then using openssh-gssapi-overwrite-base-5.0.p1,1
with the KRB5_HOME flag set to the directory of heimdal. Same thing
there, compile and make a package on one machine. The KDC's run FreeBSD
7 and the same release of heimdal as the others.


Hi,
Thanks for the response!  When you installed heimdal 1.1 
from the source, did you overwrite the local libs, or did you keep 
everything in /usr/local ?  Also, do you use hx509 at all and certs 
for pre-auth ?


---Mike



On Sun, Sep 07, 2008 at 07:55:26AM -0400, Mike Tancsa wrote:
> We are looking at deploying Kerberos for better user management (SSO)
> and 2 factor authentication via pkcs#11 etokens.  The servers are all
> FreeBSD and the machines principals will login from a mix of FreeBSD,
> Windows and MAC OSX using ssh and openvpn.  As part of our compliance
> project, access must be 2 factor.  The Heimdal in RELENG_7 is a
> rather old version and doesnt seem to have all the bits needed for
> x509 pre-auth so I would probably need to install from the ports
> anyways.   Does anyone have any suggestions as to which
> implementation to use ? We are in Canada so it doesnt matter
> regulation wise. Is one better maintained than the other ?  There are
> no legacy v4 apps
> Thanks,
>
> ---Mike
>
> ----
> Mike Tancsa,  tel +1 519 651 3400
> Sentex Communications,[EMAIL PROTECTED]
> Providing Internet since 1994www.sentex.net
> Cambridge, Ontario Canada www.sentex.net/mike
>
> ___
> freebsd-security@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"


___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: MD5 vs. SHA1 hashed passwords in /etc/master.passwd: can we configure SHA1 in /etc/login.conf?

[Mike Tancsa]

At 04:45 PM 1/3/2009, O. Hartmann wrote:


followed by a obligatory "cap_mkdb" seems to do something - changing
root's password results in different hashes when selecting different
hash algorithms like des, md5, sha1, blf or even sha256.

Well, I never digged deep enough into the source code to reveal the
magic and truth, so I will ask here for some help. Is it possible to
change the md5-algorithm by default towards sha1 as recommended after
the md5-collisions has been published?


Are you sure sha1 is supported ? It looks like if you put in 
something not understood in the login.conf file, it defaults to what 
appears to be DES.


---Mike


Thanks in advance,
Oliver
___
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"


___
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"

Openssl advisory ?

[Mike Tancsa]

Just wondering if this impacts FreeBSD's version in any significant way ?

http://www.openssl.org/news/secadv_20090325.txt

---Mike



Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
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 bug grants local root access (FreeBSD 6.x)

[Mike Tancsa]

At 05:08 AM 9/15/2009, Xin LI wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Frederique Rijsdijk wrote:
> Hi,
>
> Any info on this subject on
>
> http://www.theregister.co.uk/2009/09/14/freebsd_security_bug/

Currently we (secteam@) are testing the correction patch and do
peer-review on the security advisory draft, the bug was found and fixed
on -HEAD and 7-STABLE before 7.1-RELEASE during some stress test but was
not recognized as a security vulnerability at that time.  The exploit
code has to be executed locally, i.e. either by an untrusted local user,
or be exploited in conjunction with some remote vulnerability on
applications that allow the attacker to inject their own code.

We can not release further details about the problem at this time,
though, but I think we will likely to publish the advisory and
correction patch this patch Wednesday.


Hi,
Just wondering if there is any update on this issue ?

---Mike

--------
Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
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: Increase in SSH attacks as of announcement of rtld bug

[Mike Tancsa]

At 12:23 PM 12/1/2009, Brett Glass wrote:

Everyone:

I don't know if it's a coincidence, but I doubt it is: Since the 
announcement of the rtld bug, we've seen a precipitous increase in 
the number of SSH



http://isc.sans.org/trends.html
and
http://isc.sans.org/port.html

Do not seem to show any increase.

---Mike



--------
Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
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: Increase in SSH attacks as of announcement of rtld bug

[Mike Tancsa]

At 08:44 PM 12/1/2009, Brett Glass wrote:

At 12:09 PM 12/1/2009, Mike Tancsa wrote:


http://isc.sans.org/trends.html
and
http://isc.sans.org/port.html

Do not seem to show any increase.


Do those stats account for the fact that the attackers may first be 
fingerprinting servers to see if they're running FreeBSD?


No idea. But looking at the logs of various hosts targeted by 
distributed scanners that hit my network, they dont seem to be that 
intelligent. There is no reason it couldnt be done, but I havent seen 
it yet here anyways.


---Mike



--Brett



Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
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: Increase in SSH attacks as of announcement of rtld bug

[Mike Tancsa]

At 07:51 AM 12/2/2009, Mohd Fazli Azran wrote:

>
Seem they use multi host and brute force. My network are every day
increasing the activity of attempt ssh login with multiple host +
multiple login with multiple password. seem i got many of this messages

Yes, thats the latest pattern I have been seeing-- distributed, slow 
and coordinated.  Here is a sample from one of my honeypots.  The 
only way to deal with them I found is to have multiple sensors 
throughout my network and aggregate the data.  Otherwise, each IP 
only appears every few hrs in the logs.  In the snippet below, 
195.135.140.107 hit the one box 5hrs later, but I had a dozen hits 
total in that short period elsewhere in my network



Nov 24 05:19:09 server sshd[99051]: Invalid user daily from 
195.135.140.107
Nov 24 05:21:43 server sshd[19081]: Invalid user daily from 
78.36.196.2
Nov 24 05:23:40 server sshd[33746]: Invalid user daily from 
62.123.229.20
Nov 24 05:31:18 server sshd[88003]: Invalid user neomail from 
212.57.104.168
Nov 24 05:33:26 server sshd[11552]: Invalid user packages from 
217.70.139.42
Nov 24 05:41:54 server sshd[2430]: Invalid user packages from 
94.82.179.33
Nov 24 05:46:39 server sshd[30961]: Invalid user raqbackup from 
99.63.133.121
Nov 24 05:51:27 server sshd[53631]: Invalid user raqbackup from 
58.68.30.14
Nov 24 05:54:11 server sshd[72915]: Invalid user spool from 
193.85.165.141
Nov 24 05:56:39 server sshd[93869]: Invalid user spool from 
88.79.68.190
Nov 24 06:05:33 server sshd[53698]: Invalid user support from 
91.144.140.84
Nov 24 06:09:12 server sshd[99870]: Invalid user techsupport from 
190.96.169.145
Nov 24 06:12:41 server sshd[14339]: Invalid user techsupport from 
221.6.14.108
Nov 24 06:14:53 server sshd[25984]: Invalid user techsupport from 
89.97.228.190
Nov 24 06:16:37 server sshd[35437]: Invalid user techsupport from 
62.23.130.173
Nov 24 06:20:04 server sshd[45740]: Invalid user customer from 
221.148.90.73
Nov 24 06:30:24 server sshd[22798]: Invalid user michael from 
200.6.208.158
Nov 24 06:32:57 server sshd[50955]: Invalid user michael from 
82.212.49.128
Nov 24 06:38:13 server sshd[78472]: Invalid user michael from 
80.32.236.113
Nov 24 14:15:58 server sshd[53503]: Invalid user folder from 
194.78.138.227
Nov 24 14:18:29 server sshd[71545]: Invalid user rpcuser from 
116.55.226.131
Nov 24 14:21:12 server sshd[6]: Invalid user rpcuser from 
190.67.23.122
Nov 24 14:26:21 server sshd[19058]: Invalid user rpcuser from 
212.243.41.9
Nov 24 14:34:11 server sshd[79740]: Invalid user rpcuser from 
217.70.139.42
Nov 24 14:19:32 server sshd[35166]: Invalid user rpcuser from 
213.140.19.143
Nov 24 14:32:14 server sshd[47004]: Invalid user rpcuser from 
212.0.127.98
Nov 24 14:34:46 server sshd[55993]: Invalid user rpcuser from 
212.0.127.98
Nov 24 14:47:30 server sshd[80927]: Invalid user rpcuser from 
95.91.122.220
Nov 24 14:50:02 server sshd[99146]: Invalid user rpcuser from 
213.140.19.143
Nov 24 14:52:42 server sshd[17685]: Invalid user rpcuser from 
218.69.27.138
Nov 24 15:01:39 server sshd[78630]: Invalid user rpcuser from 
90.182.107.194
Nov 24 15:03:15 server sshd[94459]: Invalid user rpcuser from 
212.0.127.98
Nov 24 15:06:56 server sshd[25865]: Invalid user security from 
85.126.145.125
Nov 24 15:08:18 server sshd[39544]: Invalid user security from 
58.68.30.14
Nov 24 15:12:18 server sshd[59293]: Invalid user security from 
217.220.124.90





Did not receive identification from X.X.X.X

Mohd Fazli Azran
System Analysis
KL Malaysia


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.12 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksWYrsACgkQNF5f3mz2bZm2QwCfTZhxaAu586n66tGoAoX2DzjH
Wd0AmgMQyxsmJ+eoeDEgJOdXMk2SxiaB
=Ymfg
-END PGP SIGNATURE-


----
Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
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: Increase in SSH attacks as of announcement of rtld bug

[Mike Tancsa]

At 08:51 AM 12/2/2009, Poul-Henning Kamp wrote:

In message <200912021324.nb2doc58001...@lava.sentex.ca>, Mike Tancsa writes:
>At 07:51 AM 12/2/2009, Mohd Fazli Azran wrote:

>The only way to deal with them I found [...]

A very efficient measure:  Move your sshd to another port number.


As an ISP, this is not always an easy option :(   For some of our 
hosts that have ssh open to the world for our travelling staff, we do 
have it running on alternate ports. However, for a large and changing 
customer base, it causes other support problems :(


---Mike



----
Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
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"

tripwire and device numbers

[Mike Tancsa]

While getting a box ready for deployment, I noticed on two occasions, 
I would get some exception reports flagging all files as the 
underlying device number through reboots had changed.  Is this 
"normal" for Tripwire and FreeBSD ? (RELENG_7)


The file system is on
da0 at twa0 bus 0 target 0 lun 0
da0:  Fixed Direct Access SCSI-5 device
da0: 100.000MB/s transfers
da0: 238408MB (488259584 512 byte sectors: 255H 63S/T 30392C)
SMP: AP CPU #1 Launched!


eg.

Rule Name: Local files (/usr/local/sbin)
Severity Level: 66
---
  
  Modified Objects: 10
  

Modified object name:  /usr/local/sbin

  Property:ExpectedObserved
  ---- ---
  Object Type  Directory   Directory
* Device Number92  98
  Inode Number 2637949 2637949
  Mode drwxr-xr-x  drwxr-xr-x
  Num Links2   2
  UID  root (0)root (0)
  GID  wheel (0)   wheel (0)
  Size 512 512
  Modify Time  Wed Mar  3 15:24:02 2010Wed Mar  3 15:24:02 2010
  Blocks   4   4


---Mike



----
Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
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: tripwire and device numbers

[Mike Tancsa]

At 03:51 PM 3/4/2010, Dag-Erling Smørgrav wrote:

Mike Tancsa  writes:
> While getting a box ready for deployment, I noticed on two occasions,
> I would get some exception reports flagging all files as the
> underlying device number through reboots had changed.  Is this
> "normal" for Tripwire and FreeBSD ?

FreeBSD does not have fixed device numbers, they are allocated on the
fly as each device attaches.  I don't know if there is a way around
this.



OK, I think there is a way around it in the config file.

I am thinking the FreeBSD default config could be changed to


 @@section FS
-SEC_CRIT  = $(IgnoreNone)-SHa ;  # Critical files that cannot change
-SEC_SUID  = $(IgnoreNone)-SHa ;  # Binaries 
with the SUID or SGID flags set

-SEC_BIN   = $(ReadOnly) ;# Binaries that should not change
-SEC_CONFIG= $(Dynamic) ; # Config 
files that are changed infrequently but accessed often
-SEC_TTY= $(Dynamic)-ugp ;# Tty files 
that change ownership at login
-SEC_LOG   = $(Growing) ; # Files 
that grow, but that should never change ownership
-SEC_INVARIANT = +tpug ;  # 
Directories that should never change permission or ownership

+SEC_CRIT  = $(IgnoreNone)-SHad ;  # Critical files that cannot change
+SEC_SUID  = $(IgnoreNone)-SHad ;  # Binaries 
with the SUID or SGID flags set

+SEC_BIN   = $(ReadOnly)-d ;# Binaries that should not change
+SEC_CONFIG= $(Dynamic)-d ; # Config 
files that are changed infrequently but accessed often
+SEC_TTY= $(Dynamic)-ugpd ;# Tty 
files that change ownership at login
+SEC_LOG   = $(Growing)-d ; # Files 
that grow, but that should never change ownership
+SEC_INVARIANT = +tpug-d ;  # 
Directories that should never change permission or ownership
 SIG_LOW   = 33 ; # 
Non-critical files that are of minimal security impact
 SIG_MED   = 66 ; # 
Non-critical files that are of significant security impact
 SIG_HI= 100 ;# Critical 
files that are significant points of vulnerability





Where

  ##
 #  Predefined 
Variables  #

##
#
#  Property Masks
#
#  -  ignore the following properties
#  +  check the following properties
#
#  a  access timestamp (mutually exclusive with +CMSH)
#  b  number of blocks allocated
#  c  inode creation/modification timestamp
#  d  ID of device on which inode resides
#  g  group id of owner
#  i  inode number
#  l  growing files (logfiles for example)
#  m  modification timestamp
#  n  number of links
#  p  permission and file mode bits
#  r  ID of device pointed to by inode (valid only for device objects)
#  s  file size
#  t  file type
#  u  user id of owner
#
#  C  CRC-32 hash
#  H  HAVAL hash
#  M  MD5 hash
#  S  SHA hash
#


I have bcc'd the maintainer for input
Thanks,

---Mike





----
Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
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: tripwire and device numbers

[Mike Tancsa]

At 06:59 AM 3/5/2010, Dag-Erling Smørgrav wrote:

"Poul-Henning Kamp"  writes:
> Mike Tancsa  writes:
> > While getting a box ready for deployment, I noticed on two
> > occasions, I would get some exception reports flagging all files as
> > the underlying device number through reboots had changed.  Is this
> > "normal" for Tripwire and FreeBSD ? (RELENG_7)
> Yes, device numbers in freebsd carry no meaning, unless it is a compat
> /dev directory to boot ancient systems (SunOS, very old FreeBSD etc)
> diskless.
>
> In general, tripwire should ignore devfs and possibly all pseudo-fs
> mount-points.

Nothing to do with devfs; IIUC, tripwire is complaining about st.st_dev
on regular files and directories.


Correct. It was upset by just regular files and 
directories on regular file systems in /usr/bin /sbin etc.


---Mike


DES
--
Dag-Erling Smørgrav - d...@des.no


----
Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
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: ~/.login_conf mechanism is flawed

[Mike Tancsa]

Are there any other tricks / work around people have implemented ?  MACs ?

---Mike


At 11:25 AM 8/10/2010, Janne Snabb wrote:

On Tue, 10 Aug 2010, Janne Snabb wrote:

> Looks like the per-user login capability database (~/.login_conf,
> ~/.login_conf.db) functionality is creating a vulnerability.

Attached is a temporary workaround for anyone who is worried about
this problem. It disables per-user login capability databases
completely. Only the system wide /etc/login.conf is used. Do not
apply the patch if you need per-user login capabilities.

This should work on 8.1-RELEASE, most likely on some other releases
as well. I did not find any references to the evil ~/.login_conf{,.db}
anywhere else in the source except in lib/libutil/login_cap.c.

1. Save the attached login_cap.c.diff in /tmp

2. cd /usr/src/lib/libutil

3. patch < /tmp/login_cap.c.diff

4. make

5. make install

6. re-start any affected daemons:
   /etc/rc.d/sshd restart
   /etc/rc.d/ftpd restart

The relevant files are /lib/libutil.* and /usr/lib/libutil.* if you
build on one machine and distribute binaries to others. Re-start
the relevant daemons at each machine after updating the libutil
libraries.

--
Janne Snabb / EPIPE Communications
sn...@epipe.com - http://epipe.com/

___
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"


--------
Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
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: Allegations regarding OpenBSD IPSEC

[Mike Tancsa]

On 12/15/2010 6:36 AM, Andy Kosela wrote:
> 
> Some of you probably already read this:
> 
>  http://marc.info/?l=openbsd-tech&m=129236621626462&w=2
> 
> Interesting...I wonder what is the impact of all this on FreeBSD code.
> We may very well suppose that any government or corporation funded code
> can theoretically have some kind of backdoor inside.

Seems possible. However, not very probable IMHO.  As others have said,
would the guy really have a 10yr NDA, afterwords which would allow him
to post such details ? Seems rather silly on that alone.  The further
unfortunate thing about this is that any number of potential
implementation bugs can now be clouded in conspiracy theory.

http://marc.info/?l=openbsd-tech&m=129237675106730&w=2

Hell, if people believe 9/11 was all staged, ipsec backdoors are a no
brainer.  I can see it now. The next bug that is found in the crypto
system or network stack will draw a flood of discussion. "Is this the
back door??"

Seems to be getting industry reporting too

http://napps.networkworld.com/news/2010/121510-former-contractor-says-fbi-put.html?hpg1=bn


---Mike
___
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"

Old SSH bug on RELENG_4

[Mike Tancsa]

I am sure someone has some boxes out there still

http://lists.grok.org.uk/pipermail/full-disclosure/2011-June/081722.html

A simple work around *seems* to be to disable PAM on sshd. i.e in
/etc/ssh/sshd_config

set the following from yes to no

# Change to no to disable PAM authentication
ChallengeResponseAuthentication no

I wonder if other apps that make use of PAM can trigger the bug as well ?

---Mike

-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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: PAM modules

[Mike Tancsa]

On 9/16/2011 3:10 PM, Corey Smith wrote:
> On 09/16/2011 11:05 AM, Dag-Erling Smørgrav wrote:
>>  My question is: which ones?
> 
> security/pam_ssh_agent_auth
> 
> It is BSD licensed and handy for sudo.


Neato, I didnt know of this module for sudo!  However, with the default
install on AMD64, I am getting coredump.

I added


 # auth
 auth   include system
-
+auth   sufficient  /usr/local/lib/pam_ssh_agent_auth.so
file=/etc/sudokeys debug
 # account
 accountinclude system

to /usr/local/etc/pam.d/sudo

and added

--- sudoers.sample  2011-09-19 13:24:56.0 -0400
+++ sudoers 2011-09-19 13:29:17.0 -0400
@@ -62,6 +62,10 @@
 ## Uncomment to enable special input methods.  Care should be taken as
 ## this may allow users to subvert the command being run via sudo.
 # Defaults env_keep += "XMODIFIERS GTK_IM_MODULE QT_IM_MODULE
QT_IM_SWITCHER"
+
+Defaults env_keep += SSH_AUTH_SOCK
+
+


I must be missing something obvious?

---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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"

pam_ssh_agent_auth coredump on AMD64 (was Re: PAM modules)

[Mike Tancsa]

On 9/19/2011 2:00 PM, Mike Tancsa wrote:
> On 9/16/2011 3:10 PM, Corey Smith wrote:
>> On 09/16/2011 11:05 AM, Dag-Erling Smørgrav wrote:
>>>  My question is: which ones?
>>
>> security/pam_ssh_agent_auth
>>
>> It is BSD licensed and handy for sudo.
> 
> 
> Neato, I didnt know of this module for sudo!  However, with the default
> install on AMD64, I am getting coredump.

Actually, I tried the same setup on i386 and it seems to work just fine.
 However, on an AMD64 machine, sudo just coredumps.  Anyone running this
setup on amd64 ?

Running with -D9, normally it looks something like

% sudo -D9 su
sudo: settings: debug_level=9
sudo: settings: progname=sudo
sudo: settings: network_addrs=
sudo: sudo_mode 1
sudo: policy plugin returns 1
sudo: command info: umask=022
sudo: command info: command=/usr/bin/su
sudo: command info: runas_uid=0
sudo: command info: runas_gid=0
sudo: command info: runas_groups=0,5
sudo: command info: closefrom=3
sudo: command info: set_utmp=true
sudo: command info: login_class=default

where as on amd64,

% sudo -D9 su
sudo: settings: debug_level=9
sudo: settings: progname=sudo
sudo: settings: network_addrs=
sudo: sudo_mode 1
Segmentation fault

It seems to die in the call to

static int
policy_check(struct plugin_container *plugin, int argc, char * const argv[],
char *env_add[], char **command_info[], char **argv_out[],
char **user_env_out[])
{
return plugin->u.policy->check_policy(argc, argv, env_add, command_info,
argv_out, user_env_out);
}


I cant get it to coredump since its setuid.  Before I start adding more
debug printfs, does anyone have any suggestions as to what it might be ?


---Mike


> 
> I added
> 
> 
>  # auth
>  auth   include system
> -
> +auth   sufficient  /usr/local/lib/pam_ssh_agent_auth.so
> file=/etc/sudokeys debug
>  # account
>  accountinclude system
> 
> to /usr/local/etc/pam.d/sudo
> 
> and added
> 
> --- sudoers.sample  2011-09-19 13:24:56.0 -0400
> +++ sudoers 2011-09-19 13:29:17.0 -0400
> @@ -62,6 +62,10 @@
>  ## Uncomment to enable special input methods.  Care should be taken as
>  ## this may allow users to subvert the command being run via sudo.
>  # Defaults env_keep += "XMODIFIERS GTK_IM_MODULE QT_IM_MODULE
> QT_IM_SWITCHER"
> +
> +Defaults env_keep += SSH_AUTH_SOCK
> +
> +
> 
> 
> I must be missing something obvious?
> 
>   ---Mike
> 
> 


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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: pam_ssh_agent_auth coredump on AMD64 (was Re: PAM modules)

[Mike Tancsa]

On 9/20/2011 3:21 PM, Gary Palmer wrote:
> 
> If you do
> 
> sysctl kern.sugid_coredump=1
> 
> can you get a coredump?


Tried that too.

% sysctl -a | grep core
kern.corefile: %N.core
kern.nodump_coredump: 0
kern.coredump: 1
kern.sugid_coredump: 1
debug.elf64_legacy_coredump: 1
debug.elf32_legacy_coredump: 1

Actually, my mistake on i386. It seems the plugin works with

sudo-1.8.1_5

but not 1.8.2

Seems to die in the function policy_check in sudo.c


return plugin->u.policy->check_policy(argc, argv, env_add, command_info,
argv_out, user_env_out);
}




---Mike
-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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: pam_ssh_agent_auth coredump on AMD64 (was Re: PAM modules)

[Mike Tancsa]

On 9/20/2011 5:39 PM, Corey Smith wrote:
> On Tue, Sep 20, 2011 at 4:08 PM, Mike Tancsa  wrote:
>> Seems to die in the function policy_check in sudo.c
> 
> I am able to reproduce it as well on 8.2-RELEASE amd64,
> pam_ssh_agent_auth-0.9.3 and sudo-1.8.2.
> 

I posted the question on the sudo list and there seems to be a work
around posted there!

http://www.sudo.ws/pipermail/sudo-users/2011-September/004831.html

---Mike


-- 
-------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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: Latest bind advisory

[Mike Tancsa]

On 11/17/2011 9:29 PM, sys Admin wrote:
> Hi
> Any plans to apply these patches to the bind version shipped with FreeBSD ?
> 
> http://www.isc.org/software/bind/advisories/cve-2011-tbd

Hi,
They were committed already to RELENG_7,8 and 9

eg
http://lists.freebsd.org/pipermail/svn-src-stable-8/2011-November/006315.html



---Mike

-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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"

ftpd security issue ?

[Mike Tancsa]

Saw this on FD... Anyone know any more details about this ?

http://lists.grok.org.uk/pipermail/full-disclosure/2011-November/084372.html


---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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 ?

[Mike Tancsa]

On 11/30/2011 7:01 PM, Xin LI wrote:
> 
>> BTW. This vulnerability affects only configurations, where
>> /etc/ftpchroot exists or anonymous user is allowed to create files
>> inside etc and lib dirs.
> 
> This doesn't seem to be typical configuration or no?

I think in shared hosting environments it would be somewhat common.  For
annon ftp, I dont think the anon user would be able to create / write to
a lib directory.

> 
> Will the attached patch fix the problem?
> 
> (I think libc should just refuse /etc/nsswitch.conf and libraries if
> they are writable by others by the way)

It does not seem to prevent the issue for me.  Using Przemyslaw  program's,

#include 
#include 

void _init() {
setuid(0);
setgid(0);
FILE *fp = fopen("/newfile", "w+");
fprintf(fp, "%d %d\n", getuid(), geteuid());
}

cc -o dummy.o -c dummy.c -fPIC ; cc -shared -Wl,-soname,dummy.so -o
dummy.so dummy.o -nostartfiles ; mv dummy.so
~testuser/lib/nss_compat.so.1 ; chown testuser ~testuser/lib/nss_compat.so.1


ftp localhost
Trying 127.0.0.1...
Connected to localhost.
220 vmtest.localdomain FTP server (Version 6.00LS) ready.
Name (localhost:mdtancsa): testuser
331 Password required for testuser.
Password:
230 User testuser logged in, access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> dir
229 Entering Extended Passive Mode (|||62436|)
150 Opening ASCII mode data connection for '/bin/ls'.
total 106
-rw-r--r--  1 1002  1002763 Nov 30 15:17 .cshrc
-rw---  1 1002  1002193 Nov 30 16:36 .history
drwxr-xr-x  2 1002  1002512 Nov 30 16:05 etc
-r-xr-xr-x  1 0 1002  95076 Nov 30 19:50 ftpd
drwxr-xr-x  2 1002  1002512 Nov 30 19:56 lib
-rw-r--r--  1 0 1002 79 Nov 30 16:34 t.c
-rwxr-xr-x  1 0 1002 24 Nov 30 16:37 t.sh
226 Transfer complete.
ftp> dir
229 Entering Extended Passive Mode (|||50577|)
150 Opening ASCII mode data connection for '/bin/ls'.
total 108
-rw-r--r--  1 1002  1002763 Nov 30 15:17 .cshrc
-rw---  1 1002  1002193 Nov 30 16:36 .history
drwxr-xr-x  2 1002  1002512 Nov 30 16:05 etc
-r-xr-xr-x  1 0 1002  95076 Nov 30 19:50 ftpd
drwxr-xr-x  2 1002  1002512 Nov 30 19:56 lib
-rw-r--r--  1 0 1002  4 Nov 30 19:58 newfile
-rw-r--r--  1 0 1002 79 Nov 30 16:34 t.c
-rwxr-xr-x  1 0 1002     24 Nov 30 16:37 t.sh
226 Transfer complete.
ftp>

the file created is root


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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 ?

[Mike Tancsa]

On 11/30/2011 8:16 PM, Xin LI wrote:
> 
> Sorry I patched at the wrong place, this one should do.
> 
> Note however this is not sufficient to fix the problem, for instance
> one can still upload .so's that run arbitrary code at his privilege,
> which has to be addressed in libc.  I need some time to play around
> with libc to really fix this one.

Hi,
Yes, that looks better!  With respect to users uploading .so files, I
guess why not just upload executables directly ?  Although I suppose if
they are not allowed to execute anything, this would be a way around that.

Now to prod the proftpd folks

---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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 ?

[Mike Tancsa]

On 11/30/2011 8:16 PM, Xin LI wrote:
> On 11/30/11 17:01, Mike Tancsa wrote:
>> On 11/30/2011 7:01 PM, Xin LI wrote:
>>>
>>>> BTW. This vulnerability affects only configurations, where 
>>>> /etc/ftpchroot exists or anonymous user is allowed to create
>>>> files inside etc and lib dirs.
>>>
>>> This doesn't seem to be typical configuration or no?
> 
>> I think in shared hosting environments it would be somewhat common.
>> For annon ftp, I dont think the anon user would be able to create /
>> write to a lib directory.
> 
>>>
>>> Will the attached patch fix the problem?
>>>
>>> (I think libc should just refuse /etc/nsswitch.conf and libraries
>>> if they are writable by others by the way)
> 
>> It does not seem to prevent the issue for me.  Using Przemyslaw
>> program's,
> 
> Sorry I patched at the wrong place, this one should do.
> 
> Note however this is not sufficient to fix the problem, for instance
> one can still upload .so's that run arbitrary code at his privilege,
> which has to be addressed in libc.  I need some time to play around
> with libc to really fix this one.

Forgive the naive question, but is there a way to prevent a process (in
this case proftpd) from loading a .so if the session is in a chrooted
environment ?  Or if at the start of the process, is there a way to
force the process to load a lib so that later on, it wont try and load
the "bad" lib ?

---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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 ?

[Mike Tancsa]

On 12/5/2011 2:48 PM, Xin Li wrote:
> 
> Currently no (I thought you were in the cc list in my discussion with
> kib@?).  My initial plan was simply rejecting .so's with wrong
> permissions but in the discussion turns out that would not be
> sufficient and we have also considered other ways to do it, e.g. have
> a wrapper where one can disable them completely.  I have not a full
> solution yet as the change would touch quite a lot of things in the
> base system...

Hi Xin,
yes, I am on the cc list. I vaguely understand the complexity of the
issue enough to see its not an easy fix.  In the mean time, I was just
looking for ways to protect the few boxes I have that run proftpd.
Right now running with "rootrevoke on" seems to be the safest, but that
has the side effect of killing active connections.

    ---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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 ?

[Mike Tancsa]

On 11/30/2011 8:37 PM, Mike Tancsa wrote:
> On 11/30/2011 8:16 PM, Xin LI wrote:
>>
>> Sorry I patched at the wrong place, this one should do.
>>
>> Note however this is not sufficient to fix the problem, for instance
>> one can still upload .so's that run arbitrary code at his privilege,
>> which has to be addressed in libc.  I need some time to play around
>> with libc to really fix this one.
> 
> Hi,
>   Yes, that looks better!  With respect to users uploading .so files, I
> guess why not just upload executables directly ?  Although I suppose if
> they are not allowed to execute anything, this would be a way around that.
> 
> Now to prod the proftpd folks

I was testing sshd when the user's sftp session is chrooted to see how
it behaves. Because of the safety design of the way sshd is written, its
not possible to do this out of the box.  The person would first need to
create those files as root since the chroot directory is not writeable
by the user as explained in
http://www.gossamer-threads.com/lists/openssh/dev/44657

But if somehow the user is able to create those directories at the top,
or those directories are created ahead of time for the user thats
writeable by them, the bogus lib will and does run in the user's context.

I dont imagine this is common, but I am sure there is some potential
foot shooting going on.  Looking at the scponly port, it seems well
aware of this based on the suggested setup.  But again, foot shooting
could happen if the lib path is not secured properly.

Other than having /etc/nsswitch.conf, are there any other methods that
would trigger loading of shared libs in the chrooted environment ?

---Mike











-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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"

logging _rtld errors

[Mike Tancsa]

Are there any security reasons as to why

http://www.freebsd.org/cgi/query-pr.cgi?pr=142258  ([patch] rtld(1): add
ability to log or print rtld errors)

would not have been committed to the tree ?

---Mike
-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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: Default password hash

[Mike Tancsa]

On 6/8/2012 8:51 AM, Dag-Erling Smørgrav wrote:
> 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?

Actually, any chance of MFC'ing SHA256 and 512 in RELENG_7 ?  Its
currently not there.

RELENG_7 is supported until 2013

Sort of a security issue considering this assessment of MD5

http://phk.freebsd.dk/sagas/md5crypt_eol.html


---Mike



> 
> Index: etc/login.conf
> ===
> --- etc/login.conf  (revision 236616)
> +++ etc/login.conf  (working copy)
> @@ -23,7 +23,7 @@
>  # AND SEMANTICS'' section of getcap(3) for more escape sequences).
> 
>  default:\
> -   :passwd_format=md5:\
> +   :passwd_format=sha512:\
> :copyright=/etc/COPYRIGHT:\
> :welcome=/etc/motd:\
> :setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES:\
> 
> DES


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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: Default password hash

[Mike Tancsa]

On 6/9/2012 9:19 AM, someone wrote:
> hi,
> 
> what is needed to change from md5 to sha512 ? As all old passwd are md5, I 
> imagine there is a
> sequence of steps not to lock me out of the box. is there any place that 
> documents this ?

You need a relatively recent RELENG_8, not sure the exact date.  To
change the pass format, edit the file login.conf
cd /etc

vi /etc/login.conf

where it shows

default:\
:passwd_format=md5:\

change it to

default:\
:passwd_format=sha512:\

Regenerate the db file
cap_mkdb login.conf

The old passwd hash thats MD5 based will look something like

0(cage2)# grep testuser /etc/master.passwd
testuser:$1$0lfvk63d$WPD8y7w6o2CAU8V4kTgqR1:1004:1004::0:0:User
&:/home/testuser:/bin/sh
0(cage2)#

note the $1$

change the users passwd to something new, or just use the old passwd,
but re-enter it

1(cage2)# grep testuser /etc/master.passwd
testuser:$1$0lfvk63d$WPD8y7w6o2CAU8V4kTgqR1:1004:1004::0:0:User
&:/home/testuser:/bin/sh
0(cage2)# passwd testuser
Changing local password for testuser
New Password:
Retype New Password:
0(cage2)# grep testuser /etc/master.passwd
testuser:$6$AvBQXRlaKNv/YkM8$WhrcMomrs7mXgHAvFpETPT.T21jH9rYtsK8KKEFVOOYCm6noIHKI3JqQw67Vc/cYwTkGxnFY1zWrddiVUmk2p0:1004:1004::0:0:User
&:/home/testuser:/bin/sh
0(cage2)#


Note the $6$ in the hash, and its now super long.

If your FreeBSD version does not support sha512, Blowfish might be a
better alternative.  Note sure, perhaps others here know how safe it is

again, change the same file to

default:\
:passwd_format=blf:\

and do a cap_mkdb login.conf

0(cage2)# passwd testuser
Changing local password for testuser
New Password:
Retype New Password:
0(cage2)# grep testuser /etc/master.passwd
testuser:$2a$04$veZKfUGwqsrxWZOb/wbes.RdgQhLL.kfqyQ8Cv044rjJdFI0nSVXy:1004:1004::0:0:User
&:/home/testuser:/bin/sh
0(cage2)#

Note the $2a$

Other place to do it is in auth.conf, but I usually do it in login.conf
as shown above.

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/crypt.html



---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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: Default password hash

[Mike Tancsa]

On 6/11/2012 4:48 AM, Dag-Erling Smørgrav wrote:
> Mike Tancsa  writes:
>> Actually, any chance of MFC'ing SHA256 and 512 in RELENG_7 ?  Its
>> currently not there.
> 
> "not there" as in "not supported by crypt(3)"?

If you put in sha256|sha512 in passwd_format, the passwd that gets
chosen is DES, as in Data Encryption Standard, not Dag-Erling Smørgrav ;-)

    ---Mike



-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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: Default password hash

[Mike Tancsa]

On 6/11/2012 10:00 AM, Dag-Erling Smørgrav wrote:
> Mike Tancsa  writes:
>> Dag-Erling Smørgrav  writes:
>>> Mike Tancsa  writes:
>>>> Actually, any chance of MFC'ing SHA256 and 512 in RELENG_7 ?  Its
>>>> currently not there.
>>> "not there" as in "not supported by crypt(3)"?
>> If you put in sha256|sha512 in passwd_format, the passwd that gets
>> chosen is DES, as in Data Encryption Standard, not Dag-Erling Smørgrav
>> ;-)
> 
> This is non-trivial to fix, as the code that would need to be MFCed
> depends on libc changes.  I'm worried about collateral damage from
> MFCing those changes.
> 
> It may be possible to backport the sha2 code.

Locally, we still have a need to share some passwd files between a
couple of RELENG_8 and RELENG_7 boxes.  But it might be better to just
upgrade the new boxes to 8 if need be.  If not, is Blowfish as its
currently implemented on RELENG_7 considered strong enough ? There has
been some discussion suggesting its not and some that it is.


---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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: Default password encryption method.

[Mike Tancsa]

On 6/19/2012 10:10 AM, ian ivy wrote:
> By default FreeBSD uses MD5 to encrypt passwords. MD5 is believed to be
> more secure than e.g. DES but less than e.g. SHA512. Currently several
> major Linux distributions, uses a SHA512 mechanism. Suse Linux also offers
> a blowfish.


A late followup to this thread, but there was a decent fleshed out
article on this issue

http://arstechnica.com/security/2012/08/passwords-under-assault/

There are a few caveats/clarifications in the comments, but pretty good
overall for a non hardcore crypto audience.


---Mike



-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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"

audit events confusion

[Mike Tancsa]

On a rather full customer web server, I am trying to track down whose
web site script is trying to make outbound network connections when they
should not be.  In /etc/security/audit_control, I added to the flags line

dir:/var/audit
flags:lo,aa,-nt
minfree:5

to log failed network connection.  When I try an make an outbound
connection to something that is blocked in pf, it seems to sometimes
work.  eg. from the command line, if I manually try via telnet 8.8.8.8 25

pf shows
17:03:23.572682 rule 433/0(match): block out on em0: 64.7.x.x.17017 >
8.8.8.8.25: Flags [S], seq 1420411574, win 65535, options [mss
1460,nop,wscale 3,sackOK,TS val 177061484 ecr 0], length 0

and praudit records it as expected including the userid who tried to do it.

header,79,11,connect(2),0,Sun Jan  6 17:06:04 2013, + 439
msec,argument,1,0x3,fd,subject,tw,tw,tw,tw,tw,54100,54064,13556,64.7.yy.yy,return,failure
: Operation not permitted,4294967295,trailer,79,


But if I make a simple php script to try and connect out, again, pflog0
blocks it and logs it, but it does not show up in the audit logs


17:07:46.518501 rule 433/0(match): block out on em0: 64.7.xx.xx.36528 >
8.8.8.8.25: Flags [S], seq 1724105073, win 65535, options [mss
1460,nop,wscale 3,sackOK,TS val 177324430 ecr 0], length 0

Any idea what I am missing ?

This is a RELENG_8 box from this week.

---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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: audit events confusion

[Mike Tancsa]

On 1/6/2013 5:25 PM, Patrick Proniewski wrote:
> On 06 janv. 2013, at 23:11, Mike Tancsa wrote:
> 
>> But if I make a simple php script to try and connect out, again, pflog0
>> blocks it and logs it, but it does not show up in the audit logs
>>
>>
>> Any idea what I am missing ?
> 
> I think auditd can catch events only for users that have logged in at least 
> once. To audit Apache, I've had to install setaudit and launch httpd process 
> by using setaudit with proper flags.
> I've modified my /usr/local/etc/rc.d/apache22 file, mainly changing the start 
> command to start_cmd="apache22_auditstart" and adding the proper command 
> definition:

> I'm then able to log audit events for Apache, according to flags I've set in 
> apache22_auditflags.
> 

Hi,
    Thanks for the reply!  Where can I find setaudit ?

---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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: audit events confusion

[Mike Tancsa]

On 1/7/2013 1:48 AM, Patrick Proniewski wrote:
> On 06 janv. 2013, at 23:46, Mike Tancsa wrote:
> 
>> Hi,
>>  Thanks for the reply!  Where can I find setaudit ?
> 
> you might find some useful info here too:
> 
> http://forums.freebsd.org/showthread.php?t=23716

Thanks very much! I now see some audit logs generated.  Next step is to
reduce it down to a more manageable level.

Given the above thread, I can see how this was dejavu all over again for
you :)

If you or anyone else can point me to any other interesting resources
about the world of audit, I would love to see it. I guess some
interesting stuff is going in the 10 branch as well.

---Mike




-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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"

new OpenSSL security issues

[Mike Tancsa]

Three of them it seems

http://www.openssl.org/news/secadv_20130205.txt


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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: new OpenSSL security issues

[Mike Tancsa]

On 2/7/2013 1:24 PM, Xin Li wrote:
> 
> Note that it seems that the new OpenSSL version have introduced a 
> regression, by the way:
> 
> http://www.mail-archive.com/openssl-dev@openssl.org/msg32009.html

Hi Xin,
Looks like a new version just got released today that supposedly
fixes this regression issue.

http://www.openssl.org/source/exp/CHANGES

---Mike


-- 
-------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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: fatal: cipher_init: EVP_CipherInit: set key failed for aes128-cbc [preauth]

[Mike Tancsa]

On 7/30/2013 8:01 AM, Garrett Wollman wrote:
> Am I the only person to be seeing this log message from sshd:
> 
> fatal: cipher_init: EVP_CipherInit: set key failed for aes128-cbc [preauth]

> nice not to have my logs spammed with this.  Currently running
> openssh-portable-6.2.p2_3,1, and I think it started with upgrade to
> 6.2.


There is an open PR which can be closed now at

http://www.freebsd.org/cgi/query-pr.cgi?pr=171809

which points to


http://lists.freebsd.org/pipermail/svn-src-head/2013-May/047921.html

Change the default in /etc/ssh/sshd_config to

UsePrivilegeSeparation yes

as it sounds like you have hardware crypto on the box and you are using
UsePrivilegeSeparation sandbox
which is broken

---Mike



-- 
-------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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: http://heartbleed.com/

[Mike Tancsa]

On 4/7/2014 5:02 PM, Xin Li wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi, Thomas,

On 04/07/14 13:49, Thomas Steen Rasmussen wrote:

Hello,

http://heartbleed.com/ describes an openssl vulnerability
published today. We are going to need an advisory for the openssl
in base in FreeBSD 10 and we are also going to need an updated
port.

The implications of this vulnerability are pretty massive,
certificates will need to be replaced and so on. I don't want to
repeat the page, so go read that.


We are already working on this but building, reviewing, etc. would
take some time.



Hi,
The webpage lists

FreeBSD 8.4 (OpenSSL 1.0.1e) and 9.1 (OpenSSL 1.0.1c)

I take it this is only if you installed from the ports no ?

---Mike




--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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: http://heartbleed.com/

[Mike Tancsa]

On 4/7/2014 5:02 PM, Xin Li wrote:


The implications of this vulnerability are pretty massive,
certificates will need to be replaced and so on. I don't want to
repeat the page, so go read that.


We are already working on this but building, reviewing, etc. would
take some time.

Attached is the minimal fix (extracted from upstream git repository)
we are intending to use in the advisory for those who want to apply a
fix now, please DO NOT use any new certificates before applying fixes.


Hi,
	I am trying to understand the implications of this bug in the context 
of a vulnerable client, connecting to a server that does not have this 
extension.  e.g. a client app linked against 1.xx thats vulnerable 
talking to a server that is running something from RELENG_8 in the base 
(0.9.8.x).  Is the server still at risk ? Will the client still bleed 
information ?


---Mike


--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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: http://heartbleed.com/

[Mike Tancsa]

On 4/8/2014 10:09 AM, Merijn Verstraaten wrote:


On Apr 8, 2014, at 15:45 , Mike Tancsa wrote:

Hi,
I am trying to understand the implications of this bug in the context 
of a vulnerable client, connecting to a server that does not have this 
extension.  e.g. a client app linked against 1.xx thats vulnerable talking to a 
server that is running something from RELENG_8 in the base (0.9.8.x).  Is the 
server still at risk ? Will the client still bleed information ?

---Mike


Information can be bled from a vulnerable OpenSSL talking to a malicious peer 
(i.e. malicious peer forces heartbeat and bleeds info from the vulnerable app). 
So no, vulnerable clients can't bleed info from safe servers. More importantly, 
since the leak only occurs when talking to malicious peers, your clients should 
be safe if they only communicate with trusted servers (since, presumably, your 
own servers don't maliciously enable heartbeat and leak info from clients).

Of course it's still recommended to update your clients and renew keys, but in 
practice the risk should be minor for clients that only talk to secure servers.


Thanks!  Although we are certainly planing to update the vulnerable 
clients, this is not quite as dire and urgent as first described in the 
popular press-- at least as it applies to my client base. We also use IP 
addresses for the target servers in the client configs, so DNS poisoning 
does not apply to my scenario to trick the clients through that vector. 
 Still, there are other ways, but this reduces the risk somewhat for my 
scenario at least.


---Mike


--
-------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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's heartbleed response

[Mike Tancsa]

On 4/8/2014 1:42 PM, Chris Nehren wrote:

later, FreeBSD remains unpatched.  There are many worried
sysadmins and other users in #freebsd and elsewhere wondering
what's going on and when their systems will be patched.  So far
all we have is an unofficial gist on github and some discussion
here (which most users don't see) with no further information.
More transparency is needed.


* The port was very quickly updated.
* Xin posted a working patch to the list for those who really wanted to 
apply it.
* I think it reasonable that code touching such a CRITICAL aspect of the 
OS be *well* reviewed before getting committed.  IIRC there was a quick 
fix to an openssl bug in the past that then had to be fixed again.
* What is stopping people who care about security from joining, or 
following this mailing list ?


---Mike




--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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's heartbleed response

[Mike Tancsa]

On 4/8/2014 2:54 PM, Niklaus Schiess wrote:

Plenty of FreeBSD deployments use 1.0.1x due to the lack of TLS 1.2
support in 0.9.x. So thats not an excuse.


The FreeBSD security team only maintains advisories for the base 
distributions. What people install from the ports are not covered by 
those advisories.


Issues affecting the FreeBSD Ports Collection are covered in 
http://vuxml.freebsd.org/


---Mike


--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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: udp flood tools for freebsd

[Mike Tancsa]

On 4/14/2014 4:41 PM, gahn wrote:

are there any udp flooding tools under freebsd? we have win7 based unicorn 
machine running in the lab, wondering what is equivalent under freebsd.


Try the tools in /usr/src/tools/tools/netrate and netmap.  Netmap is 
handy if you want really high pps rates


---Mike


--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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-14:08.tcp

[Mike Tancsa]

On 4/30/2014 12:35 AM, FreeBSD Security Advisories wrote:

IV.  Workaround

It is possible to defend to these attacks by doing traffic normalization
using a firewall.  This can be done by including the following /etc/pf.conf
configuration:

scrub in all


Hi,
Is this the only pf option that will work, or is
scrub fragment reassemble
sufficient ?

---Mike


--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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: bash velnerability

[Mike Tancsa]

On 9/26/2014 5:01 PM, Bryan Drewery wrote:

On 9/26/2014 12:41 PM, Bryan Drewery wrote:

On 9/26/2014 11:51 AM, Bryan Drewery wrote:

On 9/26/2014 11:46 AM, Bartek Rutkowski wrote:

Apparently, the full fix is still not delivered, accordingly to this:
http://seclists.org/oss-sec/2014/q3/741

Kind regards,
Bartek Rutkowski



I'm pretty sure they call that a "feature". This is a bit different.


I've disabled environment function importing in the port. Using
--import-functions will allow it to work if you need it.


Hi Bryan,
	With the latest ports, bashcheck still sees some issues with bash. Are 
these false positives on FreeBSD ?


Using
https://raw.githubusercontent.com/hannob/bashcheck/master/bashcheck

Not vulnerable to CVE-2014-6271 (original shellshock)
Not vulnerable to CVE-2014-7169 (taviso bug)
./bashcheck: line 18: 54908 Segmentation fault  (core dumped) bash 
-c "true $(printf '< /dev/null

Vulnerable to CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Variable function parser inactive, likely safe from unknown parser bugs

---Mike



--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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: bash velnerability

[Mike Tancsa]

On 9/30/2014 5:25 PM, Charles Swiger wrote:

bash-3.2$ echo "Testing Exploit 4 (CVE-2014-7186)"
Testing Exploit 4 (CVE-2014-7186)
bash-3.2$ CVE7186="$(bash -c 'true </dev/null ||echo -n V)"
bash-3.2$ [ "${CVE7186}" == "V" ] && echo "VULNERABLE" || echo "NOT VULNERABLE"
NOT VULNERABLE

This being said, I'm not confident that there won't be further issues found 
with bash



What are people using to check these issues ?  I was using

https://github.com/hannob/bashcheck

Not sure if that gives false positives ? Even on linux with all patches 
applied, it coredumps on 7186.


Yet the BASH maintainer says all holes are patched ?  Or does he 
consider 2014-7186 not a security issue ?


http://lists.gnu.org/archive/html/bug-bash/2014-09/msg00341.html



# bash ./bashcheck
Not vulnerable to CVE-2014-6271 (original shellshock)
Not vulnerable to CVE-2014-7169 (taviso bug)
./bashcheck: line 18: 19749 Segmentation fault  (core dumped) bash 
-c "true $(printf '< /dev/null

Vulnerable to CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Variable function parser inactive, likely safe from unknown parser bugs
#



--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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-15:02.kmem

[Mike Tancsa]

On 1/27/2015 2:55 PM, FreeBSD Security Advisories wrote:



IV.  Workaround

No workaround is available.


If SCTP is NOT compiled in the kernel, are you still vulnerable ?

---Mike



--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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: DRAM Rowhammer exploits

[Mike Tancsa]

On 3/11/2015 2:13 PM, Konstantin Belousov wrote:


I just made somewhat dirty port of the double_sided program, available at
https://github.com/kostikbel/rowhammer-test/tree/freebsd


How many iterations does it usually take to trip up the bug if its there ?

---Mike


--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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"

latest OpenSSL advisory

[Mike Tancsa]

Could be worse, could be better

https://www.openssl.org/news/secadv_20150319.txt

---Mike


--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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-15:06.openssl

[Mike Tancsa]

tps://security.FreeBSD.org/patches/SA-15:06/openssl-0.9.8.patch
# fetch https://security.FreeBSD.org/patches/SA-15:06/openssl-0.9.8.patch.asc
# gpg --verify openssl-0.9.8.patch.asc

[FreeBSD 10.1]
# fetch https://security.FreeBSD.org/patches/SA-15:06/openssl-1.0.1.patch
# fetch https://security.FreeBSD.org/patches/SA-15:06/openssl-1.0.1.patch.asc
# gpg --verify openssl-1.0.1.patch.asc

b) Apply the patch.  Execute the following commands as root:

# cd /usr/src
# patch < /path/to/patch

c) Recompile the operating system using buildworld and installworld as
described in https://www.FreeBSD.org/handbook/makeworld.html>.

Restart all deamons using the library, or reboot the system.

VI.  Correction details

The following list contains the correction revision numbers for each
affected branch.

Branch/path  Revision
- -
stable/8/ r280266
releng/8.4/   r280268
stable/9/ r280266
releng/9.3/   r280268
stable/10/r280266
releng/10.1/  r280268
- -

To see which files were modified by a particular revision, run the
following command, replacing NN with the revision number, on a
machine with Subversion installed:

# svn diff -cNN --summarize svn://svn.freebsd.org/base

Or visit the following URL, replacing NN with the revision number:

https://svnweb.freebsd.org/base?view=revision&revision=NN>

VII. References

https://www.openssl.org/news/secadv_20150319.txt>

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-0209>

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-0286>

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-0287>

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-0288>

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-0289>

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-0293>

The latest revision of this advisory is available at
https://security.FreeBSD.org/advisories/FreeBSD-SA-15:06.openssl.asc>
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.2 (FreeBSD)

iQIcBAEBCgAGBQJVCwr1AAoJEO1n7NZdz2rnayEP/0w3Pba5k/1G0mJ1T9APNAns
hhXm0YuR/rNJ1XBooWEOctrijlsVChcIt8KvJCU9apOZWjDvm/nvaQ077GCi5RSp
jhQBs8MLVfXzwMbJ0/uBpp6ChF8uafk5O+gr8ulb2jG6VIaLkGOWPYv61aRYSGxy
R7+6FxD8M0lLbGOQGETy1HxKzeWztA2p0ILORNAsi+bF8GSJpxGhSxqDDi4+ic/C
3oEw0zT/E6DhxJovOPebKq0eGcRbv7ETqDmtNQdqbOddV+0FY1E+nHtrAo6B/Kln
rL+meBJHmLeEREROFk4OvCynuROUJGmXJGKwjN3uOVM05qcEZS4NkVhFNrxt6S5H
t3wQ02SesbA3pbmce5OuXmlJgdL57DVlMb5sQjkqPeoJ6pn6Rz7VLSgLNfXDUSxs
x/Lgx0+qLQUubMud7zT97UIvZmDqFTWXfJu5S/0Qt8BPFunmoNJttJ5Cr+brzEtu
5RLjcvkC1giVCpSXS96QbeT67uqSkMZa8gtII8bA77HBGA0Ky8AOwTAXbCiUovuH
sLwsI8KUC3lsKUh7eyLsSm2+wRHn0e6dZ1PE0JRazCnCRboTvMWK2d4R7ANdrwsq
CgtCWLRz6vbB9J4XTNupcEoZGhIA4RuOBqx43eQmaRw1HoV3vn85QP94oL5jzXBd
UQg3YfrXHDlxCsqEzN7o
=wi0T
-END PGP SIGNATURE-
___
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"





--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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"

SA-14:19 (Denial of Service in TCP packet processing) and jails issue ?

[Mike Tancsa]

ut to be vulnerable as 
the issue is investigated further.



--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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: SA-14:19 (Denial of Service in TCP packet processing) and jails issue ?

[Mike Tancsa]

On 4/29/2015 6:07 PM, Mike Tancsa wrote:


The IP being scanned is in a jail.  If I run the scan to an IP not
associated with the jail, the scan does not complain. Its only on the
jailed IP that the scan flags as problematic for this vulnerability.

If this is a false positive, how can I be sure thats the case ? I have
pcaps of the scan both against the jailed IP (with the scan saying its
vulnerable) and against an IP not associated with the jail, saying its
not an issue.




Anyone have any have any ideas what can be done to mitigate this risk if 
its real, or if its a false positive ?


 To further clarify/describe my test environment, this is a RELENG_9 
box I am testing against. I have a number of IPs aliased to lo0 
associated with jails.  If I run the Qualsys scan against an IP on this 
box that is not associated with a jail, it passes the test for SA-14:19. 
 If I run the test against an IP associated with the jail, it fails the 
test.


e.g. IP 192.168.1.1 is aliased to lo0 and associated with jail1.sentex.ca.

If I run the free qualsys scan against jail1.sentex.ca, the test fails. 
 If I stop the jail, and run the qualsys scan against the same IP, 
which is now just an aliased IP on the host machine, it passes the test. 
 I have the pcaps, but I am not sure exactly what I am looking for in 
the data. The test just says it confirmed the vulnerability with the 
following 2 tests,


Tested on port 22 with an injected SYN/RST offset by 16 bytes.
Tested on port 25 with an injected SYN/RST offset by 16 bytes.

What is it about the jail that might be causing either this issue to 
resurface, or give a false positive that its an issue ?



---Mike



--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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: SA-14:19 (Denial of Service in TCP packet processing) and jails issue ?

[Mike Tancsa]

On 5/4/2015 10:49 PM, Julian Elischer wrote:

Anyone have any have any ideas what can be done to mitigate this risk
if its real, or if its a false positive ?

Firstly I assume you are not talking about a vimage jail?

It seems unlikely that jailing affects that processing. Does the test
actually try cause the problem to occur? a tcpdump would be really nice.


Hi,
	Just a plain jail. No vimage.  It doesnt make sense to me either how 
the jail / no jail would impact it. I am guessing some sort of false 
positive as well, but I dont understand the details enough of how the 
vulnerability works and why there would even be a different result 
whether its a jail or not, whether real or not.


Here is what I did this AM.

In the parent, I stopped the jail and I bound sendmail and sshd to the 
IP 98.159.241.178 and an instance of apache so the same services would 
be visible on the scan outside the jail and inside. I then ran the scan. 
It came up clean. I then removed sendmail, sshd and apache from the IP 
addresses, and started up the jail


# sockstat | grep 98.159.241.178
# /usr/local/etc/rc.d/ezjail start scantest.sentex.ca
Configuring jails:.
Starting jails: scantest.sentex.ca.
0{vinyl6}# sockstat | grep 98.159.241.178
root sendmail   78661 5  tcp4   98.159.241.178:25 *:*
www  httpd  78659 3  tcp4   98.159.241.178:80 *:*
www  httpd  78658 3  tcp4   98.159.241.178:80 *:*
www  httpd  78657 3  tcp4   98.159.241.178:80 *:*
www  httpd  78656 3  tcp4   98.159.241.178:80 *:*
www  httpd  78655 3  tcp4   98.159.241.178:80 *:*
root httpd  78651 3  tcp4   98.159.241.178:80 *:*
root sshd   78646 4  tcp4   98.159.241.178:22 *:*
root syslogd78586 6  udp4   98.159.241.178:514*:*
#

and then restarted the scan.

Sure enough, it comes up vulnerable.  I have placed the 2 pcaps, and the 
reports in http://www.tancsa.com/jail


---Mike

--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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: SA-14:19 (Denial of Service in TCP packet processing) and jails issue ?

[Mike Tancsa]

On 5/5/2015 9:32 AM, Mike Tancsa wrote:

and then restarted the scan.

Sure enough, it comes up vulnerable.  I have placed the 2 pcaps, and the
reports in http://www.tancsa.com/jail



I setup a similar target environment for RELENG_10 but the scan seems to 
think RELENG_10 is just plain vulnerable.  Still trying to figure out / 
narrow it how it decides its vulnerable.


---Mike



--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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-15:10.openssl

[Mike Tancsa]

On 6/12/2015 7:06 AM, Dirk Meyer wrote:
> FreeBSD Security Advisories schrieb:,
> 
>> Topic:  Multiple OpenSSL vulnerabilities
>> Module: openssl
>> Announced:  2015-06-12
>> CVE Name:   CVE-2015-1788, CVE-2015-1789, CVE-2015-1790, CVE-2015-1791
>> CVE-2015-1792, CVE-2015-4000
> 
> I see a regression in the port for OpenSSL 1.0.2b:

There is also an ssh issue it seems ?

http://marc.info/?l=openssh-unix-dev&m=143412504002151&w=2


    ---Mike





-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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"

OpenSSH max auth tries issue

[Mike Tancsa]

Not sure if others have seen this yet

--


https://kingcope.wordpress.com/2015/07/16/openssh-keyboard-interactive-authentication-brute-force-vulnerability-maxauthtries-bypass/

"OpenSSH has a default value of six authentication tries before it will
close the connection (the ssh client allows only three password entries
per default).

With this vulnerability an attacker is able to request as many password
prompts limited by the “login graced time” setting, that is set to two
minutes by default."


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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: OpenSSH max auth tries issue

[Mike Tancsa]

On 7/17/2015 3:19 PM, Mike Tancsa wrote:
> --
> https://kingcope.wordpress.com/2015/07/16/openssh-keyboard-interactive-authentication-brute-force-vulnerability-maxauthtries-bypass/
> With this vulnerability an attacker is able to request as many password
> prompts limited by the “login graced time” setting, that is set to two
> minutes by default."
> 
> 

There is a patch in the OpenSSH tree to mitigate this. Any chance on
bringing this in before 10.2R ships ?


https://anongit.mindrot.org/openssh.git/patch/?id=5b64f85bb811246c59ebab



---Mike








-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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-15:22.openssh

[Mike Tancsa]

On 8/25/2015 5:27 PM, FreeBSD Security Advisories wrote:
> =
>
> 
FreeBSD-SA-15:22.opensshSecurity
Advisory
> Topic:  OpenSSH multiple vulnerabilities Affects:
> All supported versions of FreeBSD.



I know RELENG_8 is no longer supported, but does this issue impact
FreeBSD 8.x ?

---Mike


-- 
-------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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: FreeBSD Security Advisory FreeBSD-SA-15:22.openssh

[Mike Tancsa]

On 8/27/2015 3:24 AM, Dag-Erling Smørgrav wrote:
> Mike Tancsa  writes:
>> I know RELENG_8 is no longer supported, but does this issue impact
>> FreeBSD 8.x ?
> 
> Note that of the three issues mentioned here, one is not exploitable by
> an attacker and the other two presuppose a compromised pre-auth child.

For the latter two, I am trying to understand in the context of a shared
hosting system. Could one user with sftp access to their own directory
use these bugs to gain access to another user's account ?

---Mike

-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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"

https://www.freebsd.org/security/advisories/FreeBSD-SA-14:19.tcp.asc

[Mike Tancsa]

I have been testing a box against the qualys PCI scanner. For whatever
reason, RELENG 10 comes up vulnerable still to
CVE-2004-0230

Any idea why this might show as being an issue still ? Is it an issue or
just a false positive ?

---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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"

Intel hardware bug

[Mike Tancsa]

I am guessing this will impact FreeBSD as well ?

http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

---Mike

-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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: Potential band-aid for Meltdown

[Mike Tancsa]

On 1/4/2018 10:27 AM, Eric McCorkle wrote:
> I was thinking over meltdown mitigations this morning, and a thought
> occurred to me (which falls in line with general ideas I've been pursuing)

A pretty neat idea.  But in terms of keeping crypto keys safe, why not
something behind a pkcs11 interface (e.g. eToken) or tpm ?

---Mike
> 
> I realize it's not a perfect solution by far, but it would provide some
> level of mitigation (especially for things like GELI) that could hold
> people over until they can replace their hardware.



-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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: Intel hardware bug

[Mike Tancsa]

On 1/5/2018 8:30 AM, Andrew Duane wrote:
> Regardless, is there someone within FreeBSD that is working on patches for 
> this set of problems, at least for Intel? Linux already has at least some, 
> and I believe NetBSD does too. Of course Windows has already pushed out a 
> Windows10 fix, 7 and 8 are coming.


There is an official announcement on the FreeBSD site (quote below). Not
sure about NetBSD, but DragonFly seems to have published some patches.
Looks quite extensive :(

https://www.phoronix.com/scan.php?page=news_item&px=DragonFly-Meltdown-Fixed



" About the Meltdown and Spectre attacks: FreeBSD was made aware of the
problems in late December 2017. We're working with CPU vendors and the
published papers on these attacks to mitigate them on FreeBSD. Due to
the fundamental nature of the attacks, no estimate is yet available for
the publication date of patches."


---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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: Response to Meltdown and Spectre

[Mike Tancsa]

Thanks very much for the updates!

---Mike

On 1/8/2018 12:57 PM, Gordon Tetlow wrote:
> By now, we're sure most everyone have heard of the Meltdown and Spectre-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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: Response to Meltdown and Spectre

[Mike Tancsa]

On 1/12/2018 1:07 PM, Brett Glass wrote:
> All:
> 
> The fix in this patch appears to be unconditional.

The original email said

"The code will be selectable via a tunable which ..." Perhaps wait for
the final product.

---Mike



-- 
-------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-18:03.speculative_execution

[Mike Tancsa]

On 3/14/2018 12:29 AM, FreeBSD Security Advisories wrote:
> Affects:All supported versions of FreeBSD.
> Corrected:  2018-02-17 18:00:01 UTC (stable/11, 11.1-STABLE)
> 2018-03-14 04:00:00 UTC (releng/11.1, 11.1-RELEASE-p8)

Hi,
Are these corrections just AMD64 ? Or does it fix it on i386 as well ?

---Mike

-- 
-------
Mike Tancsa, tel +1 519 651 3400 x203
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada
___
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: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-18:03.speculative_execution

[Mike Tancsa]

On 3/14/2018 11:58 AM, Gordon Tetlow wrote:
> The Special Note in the advisory discusses this:

Sorry about that, my old person eyes missed over that section twice
somehow  :(

---Mike

> 
> Special Note:   Speculative execution vulnerability mitigation is a work
>                 in progress.  This advisory addresses the most significant
>                 issues for FreeBSD 11.1 on amd64 CPUs.  We expect to update
>                 this advisory to include 10.x for amd64 CPUs.  Future
> FreeBSD
>                 releases will address this issue on i386 and other CPUs.
>                 freebsd-update will include changes on i386 as part of this
>                 update due to common code changes shared between amd64 and
>                 i386, however it contains no functional changes for i386 (in
>                 particular, it does not mitigate the issue on i386).
> 
> On Wed, Mar 14, 2018 at 7:06 AM, Mike Tancsa  <mailto:m...@sentex.net>> wrote:
> 
> On 3/14/2018 12:29 AM, FreeBSD Security Advisories wrote:
> > Affects:        All supported versions of FreeBSD.
> > Corrected:      2018-02-17 18:00:01 UTC (stable/11, 11.1-STABLE)
> >                 2018-03-14 04:00:00 UTC (releng/11.1, 11.1-RELEASE-p8)
> 
> Hi,
>         Are these corrections just AMD64 ? Or does it fix it on i386
> as well ?
> 
>         ---Mike
> 


-- 
---
Mike Tancsa, tel +1 519 651 3400 x203
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada
___
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: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-19:07.mds

[mike tancsa]

On 5/15/2019 8:18 AM, Wall, Stephen wrote:
>> New CPU microcode may be available in a BIOS update from your system vendor,
>> or by installing the devcpu-data package or sysutils/devcpu-data port.
>> Ensure that the BIOS update or devcpu-data package is dated after 2014-05-14.
>>
>> If using the package or port the microcode update can be applied at boot time
>> by adding the following lines to the system's /boot/loader.conf:
>>
>> cpu_microcode_load="YES"
>> cpu_microcode_name="/boot/firmware/intel-ucode.bin"
> Is this applicable in a virtualized environment, or only on bare metal?
> If not applicable in a VM, is it at least harmless?


Actually, just tried this on RELENG_11 (r347613)  and I get

don't know how to load module '/boot/firmware/intel-ucode.bin'

In boot/loader.conf I have

cpu_microcode_load="YES"
cpu_microcode_name="/boot/firmware/intel-ucode.bin"

# ls -l /boot/firmware/intel-ucode.bin
-rw-r--r--  1 root  wheel  uarch 2571264 May 15 08:47
/boot/firmware/intel-ucode.bin

# sha256 /boot/firmware/intel-ucode.bin
SHA256 (/boot/firmware/intel-ucode.bin) =
1fdb3a25467d285394eded8039ee8ab488f074903654981d35a4cdfe6ebf12fc


___
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: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-19:07.mds

[mike tancsa]

On 5/15/2019 10:27 AM, Borja Marcos wrote:
>
>> On 15 May 2019, at 15:32, mike tancsa  wrote:
>>
>> Actually, just tried this on RELENG_11 (r347613)  and I get
>>
>> don't know how to load module '/boot/firmware/intel-ucode.bin'
>>
>> In boot/loader.conf I have
>>
>> cpu_microcode_load="YES"
>> cpu_microcode_name="/boot/firmware/intel-ucode.bin”
> I used this:
> microcode_update_enable=“YES"
>
>
> on /etc/rc.conf with the devcpu-data port installed and as far as I know it 
> updated the microcode.
>
> The script in /usr/local/etc/rc.d used cpucontrol(8) to load it.
>
> Or am I holding it wrong? 

Supposedly 2 ways to do it. When you install the port, it writes 
and I missed the part where it says running FreeBSD 12.0

-

Installing this port will allow host startup to update the CPU microcode on
a FreeBSD system automatically.  There are two methods for updating CPU
microcode: the first methods loads and applies the update before the kernel
begins booting, and the second method loads and applies updates using an
rc script.  The first method is preferred, but is currently only supported
on Intel i386 and amd64 processors running FreeBSD 12.0.  It is safe to
enable both methods.

The first method ensures that any CPU features introduced by a microcode
update are visible to the kernel.  In other words, the update is loaded
before the kernel performs CPU feature detection.

To enable updates using the first method, add the following lines to
the system's /boot/loader.conf:

cpu_microcode_load="YES"
cpu_microcode_name="/boot/firmware/intel-ucode.bin"

    ---Mike


>
>
> Borja.
>
>

___
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"

TCP SACK (CVE-2019-5599)

[mike tancsa]

Hi all,

With respect to the bugs describe in

https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md

*
*


  SACK Slowness (FreeBSD 12 using the RACK TCP Stack)

*Description:* It is possible to send a crafted sequence of SACKs which
will fragment the RACK send map. An attacker may be able to further
exploit the fragmented send map to cause an expensive linked-list walk
for subsequent SACKs received for that same TCP connection.

*Workaround #1:* Apply the patch split_limit.patch

 and
set the |net.inet.tcp.rack.split_limit| sysctl to a reasonable value to
limit the size of the SACK table.

*Workaround #2:* Temporarily disable the RACK TCP stack.

(Note that either workaround should be sufficient on its own. It is not
necessary to apply both workarounds.)

**

*How does I know if this is enabled in my default kernel on RELENG_12 ?
There is some vague mention in various forums this is not the default on
FreeBSD ? Can anyone shed more light as to how this does/does not impact
FreeBSD ?
*

*
*

*    ---Mike
*


___
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: FreeBSD Security Advisory FreeBSD-SA-19:10.ufs

[mike tancsa]

On 7/2/2019 8:49 PM, FreeBSD Security Advisories wrote:
> Special note: This update also adds the -z flag to fsck_ffs to have it scrub
> the leaked information in the name padding of existing directories.  It only
> needs to be run once on each UFS/FFS filesystem after a patched kernel is
> installed and running.
>
> # freebsd-update install
>
> Afterwards, reboot the system and run:
>
> # fsck -t ufs -f -p -T ufs:-z
>
> to clean up your existing filesystems.
>
Doesnt this need to be run in single user mode with the file system not
mounted RW ?

    ---Mike


___
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: FreeBSD Security Advisory FreeBSD-SA-19:19.mldv2

[Mike Tancsa]

Does anyone have any more details about the implication of this ? e.g.
does a daemon need to be listening on a target device ? Is it merely the
act of forwarding such packets ? Can a non root user open such a daemon ?
Thanks,

    ---Mike


> =
> FreeBSD-SA-19:19.mldv2  Security
> Advisory
>   The FreeBSD
> Project
>
> Topic:  ICMPv6 / MLDv2 out-of-bounds memory access
> MLDv2 is the Multicast Listener Discovery protocol, version 2.  It is used
> by IPv6 routers to discover multicast listeners.
>
> II.  Problem Description
>
> The ICMPv6 input path incorrectly handles cases where an MLDv2 listener
> query packet is internally fragmented across multiple mbufs.
>
> III. Impact
>
> A remote attacker may be able to cause an out-of-bounds read or write that
> may cause the kernel to attempt to access an unmapped page and
> subsequently
> panic.

___
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"

libarchive issue ?

[mike tancsa]

Hi,

    I was thinking with the 2 intel CPU SAs, there would be an SA fo
libarchive issue ?

https://nvd.nist.gov/vuln/detail/CVE-2019-18408

Or is FreeBSD not vulnerable to this particular issue ? I think as fix was

__FBSDID("$FreeBSD:
stable/12/contrib/libarchive/libarchive/archive_read_support_filter_lz4.c
353375 2019-10-09 22:18:01Z mm $");

but just wanted to make sure

Thanks!

    ---Mike

___
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"

name:wrek vulnerabilities ?

[mike tancsa]

I heard about this on the ISC stormcast podcast this AM, but I cant
quite make heads or tails of if/when what was patched with respect to
FreeBSD.

https://www.forescout.com/company/blog/forescout-and-jsof-disclose-new-dns-vulnerabilities-impacting-millions-of-enterprise-and-consumer-devices/

They have a dhclient one I think is
https://www.freebsd.org/security/advisories/FreeBSD-SA-20:26.dhclient.asc,
but the report somewhat ambiguously writes there is a new one ?

"Table 3 – New vulnerabilities in NAME:WRECK. Rows are colored according
to the CVSS score: yellow for medium or high and red for critical." Yet
the CVE ref is the above SA 20:26?! So this is new or this is just a
paper talking about a bug patched last August ?

    ---Mike







___
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"