Re: new bind security bug?
Also bad form to top post. Should i amso mispell some words so you can amuae yourself? -- Michael Scheidell, CTO SECNAP Network Security -Original message- From: Mark Andrews ma...@isc.org To: Michael Scheidell michael.scheid...@secnap.com Cc: freebsd-security@freebsd.org freebsd-security@freebsd.org Sent: Fri, Jul 8, 2011 02:20:48 GMT+00:00 Subject: Re: new bind security bug? Firstly, it is bad form to hijack a old thread and reply to it for a new topic. How hard is it to type freebsd-security@freebsd.org into a To: field and start a new topic? Additionally it may not be seen by anyone that had marked the old thread to be killed. In message 4e1652af.8000...@secnap.com, Michael Scheidell writes: is this a new one? Yes, these are new. From the referenced advisary notices. Version 2.0 - 5 July 2011: Public Disclosure The freebsd security team are aware of this. http://threatpost.com/en_us/blogs/new-bind-release-fixes-high-severity-remot e-bugs-070611 The high-severity vulnerability in many versions of the BIND software has the effect of causing the BIND server to exit when it receives a specially formatted packet. The ISC said that although it isn't aware of any public exploits for the bug, it still recommends that organizations upgrade to one of the newer versions of BIND, which include 9.6-ESV-R4-P3, 9.7.3-P3 or 9.8.0-P4. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.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
Re: 193.138.118.3 ? lagoon.freebsd.lublin.pl /cache, freebsd, lublin, pl on TOR end point list?
On 4/16/11 5:28 AM, Przemyslaw Frasunek wrote: freebsd.lublin.pl does not host any FreeBSD mirrors. It's a shell server with ~300-400 accounts, running for 14 years. I personally know (almost) every person having account here. We have TOR installed (without exit node functionality), but it's not used for any kind of illegal activities. so, option C: being too paranoid and I should get more rest :-) I will try to track down what server is lookup up cache.freebsd.lublin.pl and see why its doing that. thanks. -- Michael Scheidell, CTO o: 561-999-5000 d: 561-948-2259 ISN: 1259*1300 *| *SECNAP Network Security Corporation * Best Intrusion Prevention Product, Networks Product Guide * Certified SNORT Integrator * Hot Company Award, World Executive Alliance * Best in Email Security, 2010 Network Products Guide * King of Spam Filters, SC Magazine __ This email has been scanned and certified safe by SpammerTrap(r). For Information please see http://www.secnap.com/products/spammertrap/ __ ___ 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: packet capture and if_bridge ignore bpf rules
On 12/11/10 11:05 AM, Michael Scheidell wrote: I am just not working on tracking this down, and sometimes like to use tcpdump/tshark to watch specific packets on a host to look for 'interesting' things. I think I have seen this since 6.x I don't remember it on 5.x, but 5.x used 'bridge' and 6.x and 7.x are using if_bridge. system is 7.3, amd64. tried this on 6.x amd64, and i386. same results. googled a lot and didn't see anything I could use. im an idiot. its vlan trunked traffic, for tagged vlan packets. on the systems that don't look like they work: (tshark|tcpdump) -niem0 vlan and net 204.89.241.0/24 works just fine. -- Michael Scheidell, CTO o: 561-999-5000 d: 561-948-2259 ISN: 1259*1300 *| *SECNAP Network Security Corporation * Certified SNORT Integrator * 2008-9 Hot Company Award Winner, World Executive Alliance * Five-Star Partner Program 2009, VARBusiness * Best in Email Security,2010: Network Products Guide * King of Spam Filters, SC Magazine 2008 __ This email has been scanned and certified safe by SpammerTrap(r). For Information please see http://www.secnap.com/products/spammertrap/ __ ___ 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: any interest in tripwire commercial?
Probably. does everyone put 32 bit compatibility libraries in their amd64 builds? __ Never, unless running cosed source software. It seems to triple your attack surface area. than the answer is no' you would not want an i386 version since you need to put 32bit compatibility in if this is all tripwire supports. Sometimes, its easier to get a vendor to release compiled binaries if you tell them you can support: 7.1 - 8.x, i386/amd, with a single i386/32 bit binary. to tell them the need to maintain 8 versions is harder. doesn't really too much matter, It looks like only you and me are interested. with that huge response, I guess its never going to happen. -- Michael Scheidell, CTO o: 561-999-5000 d: 561-948-2259 ISN: 1259*1300 *| *SECNAP Network Security Corporation * Certified SNORT Integrator * 2008-9 Hot Company Award Winner, World Executive Alliance * Five-Star Partner Program 2009, VARBusiness * Best in Email Security,2010: Network Products Guide * King of Spam Filters, SC Magazine 2008 __ This email has been scanned and certified safe by SpammerTrap(r). For Information please see http://www.secnap.com/products/spammertrap/ __ ___ 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
packet capture and if_bridge ignore bpf rules
I am just not working on tracking this down, and sometimes like to use tcpdump/tshark to watch specific packets on a host to look for 'interesting' things. I think I have seen this since 6.x I don't remember it on 5.x, but 5.x used 'bridge' and 6.x and 7.x are using if_bridge. system is 7.3, amd64. tried this on 6.x amd64, and i386. same results. googled a lot and didn't see anything I could use. problem: if I am on a network using if_bridge, the 'FILTER' section of bpf seems to be ignored, or sorta backward. tried with tcpdump, tshark, snort, etc. example: normal interface: tshark -niem0 net 204.89.241.0/24 sees traffic to and from that net (tcpdump, same thing) HOWEVER.. tshark -niem0 net 204.89.241.0/24 sees NOTHING tshark -niem1 net 204.89.241.0/24 sees NOTHING tshark -nibridge0 net 204.89.241.0/24 sees NOTHING tshark (em0|em1|bridge0) sees 204.89.241.0/24 if I do this: tshark (em0|em1|bridge0) not net 204.89.241.0/24 (actually looks like it sees everything and ignores the bpf filter. using -F on tcpdump, using -f 'net 204.89.241.0/24' on wireshark doesn't help. em0 and em1 have no ip assigned and are brought up like this: ifconfig_em0=-arp up ifconfig_em1=-arp up cloned_interfaces=bridge0 ifconfig_bridge0=addm em1 stp em1 addm em0 stp em0 up ifconfig looks like this: em1: flags=89c3UP,BROADCAST,RUNNING,NOARP,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=9bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM ether 00:30:64:05:ef:56 media: Ethernet autoselect (1000baseTX full-duplex) status: active em0: flags=89c3UP,BROADCAST,RUNNING,NOARP,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=9bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM ether 00:30:64:05:ef:57 media: Ethernet autoselect (1000baseTX full-duplex) status: active bce0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=1bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4 ether 00:1d:09:6b:75:e2 inet 192.168.100.40 netmask 0xff00 broadcast 192.168.100.255 media: Ethernet autoselect (100baseTX full-duplex) status: active lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 inet 127.0.0.1 netmask 0xff00 bridge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether ea:62:40:63:41:3b id 00:1d:09:6b:75:e2 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:1d:09:6b:75:e2 priority 32768 ifcost 0 port 0 member: em0 flags=1c7LEARNING,DISCOVER,STP,AUTOEDGE,PTP,AUTOPTP ifmaxaddr 0 port 3 priority 128 path cost 200 proto rstp role designated state forwarding member: em1 flags=1e7LEARNING,DISCOVER,STP,EDGE,AUTOEDGE,PTP,AUTOPTP ifmaxaddr 0 port 2 priority 128 path cost 200 proto rstp role designated state forwarding so, what magic to make bpf filters work? -- Michael Scheidell, CTO o: 561-999-5000 d: 561-948-2259 ISN: 1259*1300 *| *SECNAP Network Security Corporation * Certified SNORT Integrator * 2008-9 Hot Company Award Winner, World Executive Alliance * Five-Star Partner Program 2009, VARBusiness * Best in Email Security,2010: Network Products Guide * King of Spam Filters, SC Magazine 2008 __ This email has been scanned and certified safe by SpammerTrap(r). For Information please see http://www.secnap.com/products/spammertrap/ __ ___ 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
any interest in tripwire commercial?
Any interest in Tripwire Commercial version? I have a client who wants to allow their enterprise tripwire console to be able to monitor the servers that do the real work (the freebsd servers) as well as the token windows servers which are being monitored now. What version would you like to see it on? one of the .[135] versions for long life? 7.3? amd64? 8.1? is i386 ok, as long as all the libraries exist? does everyone put 32 bit compatibility libraries in their amd64 builds? __ This email has been scanned and certified safe by SpammerTrap(r). For Information please see http://www.secnap.com/products/spammertrap/ __ ___ 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-08:06.bind
NOTE WELL: If a port number is specified via the query-source or query-source-v6 options to BIND, randomized port selection will not be used. Consequently it is strongly recommended that these options not be used to specify fixed port numbers -- Michael Scheidell, CTO |SECNAP Network Security Winner 2008 Network Products Guide Hot Companies FreeBSD SpamAssassin Ports maintainer From: Mark Andrews [EMAIL PROTECTED] Date: Mon, 14 Jul 2008 10:29:36 +1000 To: freebsd-security@freebsd.org Cc: FreeBSD Security Advisories [EMAIL PROTECTED] Subject: Re: FreeBSD Security Advisory FreeBSD-SA-08:06.bind There was no mention of checking named.conf to ensure that a port was not specified in the query-source clauses. Just upgrading will not fix the problem it if named.conf has query-source port 53. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED] _ This email has been scanned and certified safe by SpammerTrap(r). For Information please see http://www.spammertrap.com _ ___ 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-07:07.bind
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Byrnes Sent: Wednesday, August 01, 2007 6:13 PM To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-07:07.bind Stop in /usr/src/usr.sbin/named. Anyone receiving the same? is a fix on the way? Please cc in replies. Thank you so much! Works here: FreeBSD mirror.secnap.com 5.5-RELEASE-p14 FreeBSD 5.5-RELEASE-p14 *default release=cvs tag=RELENG_5_5 I386 and sparc64 _ This email has been scanned and certified safe by SpammerTrap(tm). For Information please see http://www.spammertrap.com _ ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: MOAB advisories
Why would you think any of these had anything to do with Freebsd? They all clearly state 'Apple DMG'. (a compressed disk image only for Apple Max OSX) -- Michael Scheidell, CTO SECNAP Network Security Corporation Web based Security and privacy Training: http://www.secnap.com/training - This email has been scanned and certified safe by SpammerTrap(tm) For Information please see http://www.spammertrap.com ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: seeding dev/random in 5.5
-Original Message- From: R. B. Riddick [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 08, 2006 4:12 AM To: Michael Scheidell; freebsd-security@freebsd.org Subject: Re: seeding dev/random in 5.5 I think that during the first reboot after a fresh install the kern.random.sys sysctl settings are already orderly before rc.d/sshd is called... If yes, then sending some pings should do the trick... Or not? I mean: NETWORKING should already be provided at that point... I am not sure I understand what you are saying in the context of my question. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: seeding dev/random in 5.5
R. B. Riddick wrote:
I was under the impression, that
kern.random.sys.harvest.ethernet
is
1
by default.
That would mean, that ethernet traffic to that deeply buried box should feed
that /dev/random until it is fat and round...
Why do u believe, that /dev/random isnt seeded by networking?
because it isn't.
and pings arn' going to produce much random data.
it might feed it LATER, saving to /var/db/entropy, but when the system
is booted, and there are no keys in /etc/ssh and rc.d/sshd tried to
generate enough to feed to /dev/random, it doesn't
At least in this case, this box, this os, this chipset. Only one I have
see like this.
Its a showstopper. Box won't start remote sshd, can only get at it via
console.
Not sure why the reluctance to even acknowledge that there could be a
minor fix/patch that could prevent dead box and a ${miles=hundreds) trek
to bring it back.
if its never happened to you, then you may not have the exact
combination I have.
I can reproduce it 100% of the time, every time, all day long.
Only two workarounds that I know of:
#1, put in more than 3 lines of garbage on console.
#2, put in more than 5 packets of garbage from ethernet
(which, acknowledged: if hacker is trying to seed known data to this
box, he could feed it known data)
--
Michael Scheidell, CTO
SECNAP Network Security / www.secnap.com
[EMAIL PROTECTED] / 1+561-999-5000, x 1131
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: seeding dev/random in 5.5
R. B. Riddick wrote: --- Michael Scheidell [EMAIL PROTECTED] wrote: R. B. Riddick wrote: Why do u believe, that /dev/random isnt seeded by networking? because it isn't. and pings arn' going to produce much random data. Hmm... Interesting... it might feed it LATER, saving to /var/db/entropy, but when the system is booted, and there are no keys in /etc/ssh and rc.d/sshd tried to generate enough to feed to /dev/random, it doesn't Hopefully... I was under the impression, that new random events are gathered continuously in order to create an always good source of random ... yes, maybe, AFTER it boots, and during the day. I can reproduce it 100% of the time, every time, all day long. OK... But I still dont understand why that is... Does it have an ethernet NIC? Is that sysctl (kern.random.sys.harvest.ethernet) set to 1 before rc.d/sshd starts? yes, has nic card (how else would I be able to ssh into it later ;-) no, rc.d/sshd doesn't touch that sysctl. Only two workarounds that I know of: #1, put in more than 3 lines of garbage on console. #2, put in more than 5 packets of garbage from ethernet (which, acknowledged: if hacker is trying to seed known data to this box, he could feed it known data) If I may add: I know another workaround: Create the key files during the install process, which has to be done quite handish anyway, if u do it on a far away deeply buried box... Or not? This would affect the generic stock 5.5 install disk as well (it doesn't create new keys when it builds a virgin hard disk) If a user just hits return, there is no error message, no indication that /dev/random wasn't seeded. We have a bootable CD rom, has a generic boot/network/vpn/ and dumpfiles for virgin install. cd rom uses restore to make new HD. Id rather like to have different keys on different boxes. ssh client complains when it sees the same keys for several different ip addresses. -Arne __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- Michael Scheidell, CTO SECNAP Network Security / www.secnap.com [EMAIL PROTECTED] / 1+561-999-5000, x 1131 ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
seeding dev/random in 5.5
I was doing some regression testing in 5.5: Specifically testing booting
up a 'virgin' hard disk from a clean install.
I was testing what happened if the 300 second timeout happened vs
hitting return for 'fast+insecure' startup and punching in a bunch of
random garbage.
I found that for some reason, on a 2.4Ghz Celeron, the 'sysctl -a' and
'date' seeding for 'fast+insecure' seemed to do nothing unless I typed
in at least 3 lines of random keystrokes.
ie: /etc/rc.d/sshd start WONT, it doesn't generate ssh keys in /etc/ssh
and ssh won't start.
Is there something in /dev/random that won't init if it isn't random enough?
(if doing this from an unattended bootup, expecting the 300 second
timeout, I find that sshd does not start!)
After doing some testing, it appears that (at least with the combination
of a 2.4Ghz Celeron and 5.5) that it takes at least three lines of
random data, added to the output of sysctl -a and date to seed /dev/random.
(as per this in /etc/rc.d/sshd:
read -t ${timeout} junk
echo ${junk} `sysctl -a` `date` /dev/random
I can find no other explanation to the results of my tests:
This removes keys:
/etc/rc.d/sshd stop
rm /etc/ssh/*key*
/etc/rc.d/sshd start
tests:
#1, allow 300 second timeout:
remove keys, restart sshd: /etc/rc.d/sshd start
let it sit for 300 seconds.
No error messages, but sshd doesn't start, and there are no keys in /etc/ssh
#2, one line of random test
(same results as above)
#3, two lines, etc
#4, three lines.
Now, I get the messages telling me that ssh_keygen has created keys, and
there are keys in /etc/ssh
I also find that by adding this to the random seeding that it will work
with return or 300 second timeout:
read -t ${timeout} junk
echo ${junk} `sysctl -a` `date` `tcpdump -xs1500 -c
5` /dev/random
Yes, I know, but even ;lj;lkj;lj;ljjl on the keyboard isn't all that
random, but my issue is not being able to remotely access a virgin
system with ssh. Sometimes these are headless pizza boxes, buried deep
in the bowels of some data center.
Has anyone else run tests like this?
(I suppose the -c value in tcpdump could be random as well '-=) using:
count = `date +%S`
In a remote location, with no head, no monitor, its hard trying to
figure out just WHY 'system won't boot'.
(it booted, but sshd didn't start!)
There is enough random[pun intended] things that can happen when you
install a new system, that I would like to try to eliminate one of them.
--
Michael Scheidell, CTO
SECNAP Network Security / www.secnap.com
[EMAIL PROTECTED] / 1+561-999-5000, x 1131
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Port scan from Apache?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, July 21, 2006 12:43 AM To: Clemens Renner Cc: freebsd-security@freebsd.org Subject: Re: Port scan from Apache? Clemens Renner wrote: Hi everyone, today I got an e-mail from a company claiming that my server is doing port scans on their firewall machine. I found that hard to believe so I started checking the box. Let me put my 2/c (CAD) into this, as a user of netscreens, the CTO of a Managed network security service. The person who sent you the 'alert' might be wrong. We see port scans from web servers (incrementing source ports 1024, destination port 80) and it is usually just noise, internet traffic, and the failure of his netscreen to properly close the connection. Can you correlate the netscreen logs with times his users have accessed your web site? Do you have complaints from just this one person? Send him a note telling him this is just normal internet traffic and that he should try to understand the three way TCP handshake, and what stateful firewalls do when they close their side of the TCP connection before you do. If it happens A LOT, to lots of different networks, then, well, it is possible you have a worm, do a tcpdump on the traffic and look for it. Another possibility, is that your web site spawns many different http threads for each user connection (do you have a zillion thumbnail gifs? Each one could spawn a different tcp connection) Do you have an unusually high keep-alive? It YOUR firewall closing (timing out) the tcp connection? Mostly, if this was just one complaint, grep your web server logs for his user connecting, tell him this is just normal tcp traffic and go about your business from then on. If he gets rude, blacklist him and/or send him a $50 lawyer letter and tell him to either drop dead or call his local FBI (or RCMP) office. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Anyone running ntop on FBSD5.4
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of talonz Sent: Sunday, June 11, 2006 7:28 PM To: Remco Bressers Cc: freebsd-security@freebsd.org Subject: Re: Anyone running ntop on FBSD5.4 Remco Bressers wrote: I had this same problem as well. disable ipv6 or tcp6 using the ntop flags found in the manual page (man 8 ntop) worked well for me. Strange, its already disabled in ports in the config. # we currently disable IPv6 CONFIGURE_ARGS+=--disable-ipv6 Tried -4, still, when I go to Summary-Traffic page, when it finally gets to bottom, it segv's Gdb shows it in myrrd library. Working with ntop people now to trace it down. Looks like there has been a long history of failures with ntop going back to 4.xx. Maybe it can finally be fixed. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
Anyone running ntop on FBSD5.4
If you are running ntop on 5.4, what compile options? Use ports version? Or surgefile tarball? It makes a great security forensics tools, but I can't get it to stop segfaulting.Was wondering if anyone found a fix for it. -- Michael Scheidell, CTO 561-999-5000, ext 1131 SECNAP Network Security Corporation Take a vacation from spam: http://www.spammertrap.com ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
Domtools.com hyjacked?
Attempted to install dlint port. Only distribution site is www.domtools.com Email to '[EMAIL PROTECTED]' and [EMAIL PROTECTED] bounces (can't relay) Phone number missing on whois record. Fetch of tarball fails checksum (it delivers a generic 'web hosted search engine that just hijacked someone's domain' web page. Maybe domtools didn't renew? New web company messed up dns or apache virtual hosting records? Don't know where else to find a safe copy of dlint ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Useful addition to ipfw
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Borja Marcos Sent: Tuesday, December 13, 2005 11:00 AM To: freebsd-security@freebsd.org Subject: Useful addition to ipfw Hello, I've found myself in a situation where a simple data inspection capability added to ipfw would be very useful. Use divert option and reinject it back in? ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
Freebsd port issue: ZDI-05-002: Clam Antivirus Remote Code Execution
This was in bugtraq, and hasn't shown up in portaudit yet so I thought I
would send it and the fix to you.
I submitted a pr for a patch as well. (but for some reason, ir bounced)
Problem #1:
Clamav 87 has been found to have a security vulnerability that
could
lead to remote code execution
Problem #2
patch patch-clamav-milter_clamav-milter.c won't apply cleanly
(and I have't the slightest idea why, or even WHAT the patch
does:
--- clamav-milter/clamav-milter.c.orig
+++ clamav-milter/clamav-milter.c
@@ -3439,9 +3439,9 @@
{
fd_set rfds;
struct timeval tv;
+ int ret;
assert(sock = 0);
- int ret;
if(readTimeout == 0) {
do
How-To-Repeat:
See:
http://www.zerodayinitiative.com/advisories/ZDI-05-002.html
when trying to compile new clamav, get this:
Applying FreeBSD patches for clamav-0.87.1
Ignoring previously applied (or reversed) patch.
1 out of 1 hunks ignored--saving rejects to
clamav-milter/clamav-milter.c.rej = Patch
patch-clamav-milter_clamav-milter.c failed to apply cleanly.
Fix:
remove patch (it looks like a dunsel)
rm files/patch-clamav-milter_clamav-milter.c
--- Makefile.orig Fri Nov 4 17:57:18 2005
+++ MakefileSat Nov 5 07:26:14 2005
@@ -6,8 +6,7 @@
#
PORTNAME= clamav
-PORTVERSION= 0.87
-PORTREVISION= 2
+PORTVERSION= 0.87.1
CATEGORIES=security
MASTER_SITES= ${MASTER_SITE_SOURCEFORGE_EXTENDED}
MASTER_SITE_SUBDIR=clamav
--- distinfo.orig Fri Nov 4 17:57:23 2005
+++ distinfoSat Nov 5 07:26:02 2005
@@ -1,2 +1,2 @@
-MD5 (clamav-0.87.tar.gz) = dd0a12deb4f48f760fa1fcd378ae7c24 -SIZE
(clamav-0.87.tar.gz) = 4273714
+MD5 (clamav-0.87.1.tar.gz) = bf9f038edf0b6d5f76552e1b8d014b81 SIZE
+(clamav-0.87.1.tar.gz) = 4468992
ZDI-05-002: Clam Antivirus Remote Code Execution Vulnerability
http://www.zerodayinitiative.com/advisories/ZDI-05-002.html
November 4th, 2005
-- CVE ID:
CAN-2005-3303
-- Affected Vendor:
Clam AntiVirus
-- Affected Products:
Clam AntiVirus 0.80 through 0.87
-- TippingPoint(TM) IPS Customer Protection:
TippingPoint IPS customers have been protected against this
vulnerability since October 24th, 2005 by Digital Vaccine protection
filter ID 3874. For further product information on the TippingPoint IPS:
http://www.tippingpoint.com
-- Vulnerability Details:
This vulnerability allows remote attackers to execute arbitrary code on
vulnerable ClamAV installations. Authentication is not required to
exploit this vulnerability.
This specific flaw exists within libclamav/fsg.c during the unpacking of
executable files compressed with FSG v1.33. Due to invalid bounds
checking when copying user-supplied data to heap allocated memory, an
exploitable memory corruption condition is created. The unpacking
algorithm for other versions of FSG is not affected.
-- Vendor Response:
The bug has been fixed in version 0.87.1. Release notes:
http://www.sourceforge.net/project/shownotes.php?release_id=368319
-- Disclosure Timeline:
2005.10.24 - Vulnerability reported to vendor
2005.10.24 - Digital Vaccine released to TippingPoint customers
2005.10.25 - Vulnerability information provided to ZDI security partners
2005.11.04 - Public release of advisory
-- Credit:
This vulnerability was discovered by an anonymous ZDI researcher.
-- About the Zero Day Initiative (ZDI):
Established by TippingPoint, a division of 3Com, The Zero Day Initiative
(ZDI) represents a best-of-breed model for rewarding security
researchers for responsibly disclosing discovered vulnerabilities.
Researchers interested in getting paid for their security research
through the ZDI can find more information and sign-up at:
http://www.zerodayinitiative.com
The ZDI is unique in how the acquired vulnerability information is used.
3Com does not re-sell the vulnerability details or any exploit code.
Instead, upon notifying the affected product vendor, 3Com provides its
customers with zero day protection through its intrusion prevention
technology. Explicit details regarding the specifics of the
vulnerability are not exposed to any parties until an official vendor
patch is publicly available. Furthermore, with the altruistic aim of
helping to secure a broader user base, 3Com provides this vulnerability
information confidentially to security vendors (including competitors)
who have a vulnerability protection or mitigation product.
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Problem with portaudit's database
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon L. Nielsen Sent: Wednesday, September 07, 2005 7:35 AM To: Dmitry Pryanishnikov Cc: freebsd-security@freebsd.org Subject: Re: Problem with portaudit's database On 2005.09.07 10:35:21 +0300, Dmitry Pryanishnikov wrote: Yesterday portaudit notified me about squid's vulnerability, but today it didn't (despite I haven't upgraded squid). This has attracted my attention, so I've compared yesterday's and today's auditfile.tbz: -r--r--r-- 1 root wheel 29875 Sep 6 15:40 auditfile.tbz vs. -r--r--r-- 1 root wheel5685 Sep 7 10:11 auditfile.tbz I had a similar problem (which was fixed with portaudit -F) so, I assume that for a short time, the audit db was corrupted. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: IPFW disconnections and resets
I use that all the time, maybe 1 out of 100 times it will kill a ssh session (only one that has irssi open cause of the time updating it kills it, i have it set to update every second though, so normally it'd be like 1 out of 500 or so) and even if it does, it still finishes loading the ruleset anyway so you can just ssh straight back in I used sysctl -a net.inet.ip.fw.enable=0 firewall.sh net.inet.ip.fw.enable=1 sleep 60 reboot and I would hit a ^c to stop the sleep and reboot if I didn't wack the firewall rules. The reboot would put it back to rc.conf firewall Never got disconnected. Only window of vulnerability was while loading new firewall rules. Yours is safer. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
