September 2003 - openSUSE Security - openSUSE Mailing Lists

Re: [suse-security] packets still seem to be dropped not routed despiterp_filter=0
by J J 16 Sep '03

16 Sep '03

Great links! Thanks for your help - it's finally working!! There was a lot of to and fro, especially as I wasn't used to iptables or SuSEfirewall2! Although I'd switched on routing using echo "1" > /proc/sys/net/ipv4/ip_forward I somehow hadn't looked quite closely enough at the debug output from SuSEfirewall2 status. I'd switched on the FW_LOG_DROP_ALL and FW_REJECT so I'd expected to see either firewall entries or at least ping packets getting bounced obviously. It seems that neither of these variables applied to the FORWARD chain on the filter table! When I did a number of experiments (ran SuSEfirewall2 status, did a standard Microsoft 4-packet-ping, quickly run SuSEfirewall2 status again and diff the results to look for things that increased by 4) I found a glaringly obvious hint that the FORWARD chain on the filter table was dropping the packets by default. The easiest but least SuSE way of doing things was to create a _updown_custom script - I copied the one from that article you pointed me to. It issues the commands... iptables -I FORWARD 1 -s 192.168.10.0/255.255.255.0 -d 192.168.0.0/255.255.255.0 -j ACCEPT iptables -I FORWARD 1 -d 192.168.10.0/255.255.255.0 -s 192.168.0.0/255.255.255.0 -j ACCEPT ...and all is well. Adding ipsec0 to the FW_DEV_EXT doesn't seem to be needed anymore, rp_filter stays as 0 anyway! Turning in for the night. Cheers fellas! Carl >From: Philipp Rusch <Philipp.Rusch(a)rusch-edv.de> >To: J J <c_peto(a)hotmail.com> >CC: "suse-security(a)suse.com" <suse-security(a)suse.com> >Subject: Re: [suse-security] packets still seem to be dropped not routed >despiterp_filter=0 >Date: Thu, 11 Sep 2003 23:54:02 +0200 > >JJ, now I found my info-links to VPN resources again: > >have a look at: > >http://www.nadmm.com/show.php?story=articles/vpn.inc > >(the author also states that ipsec0 has to be added to EXT -interface) > >and a very good source for SuSE-specific FreeS/WAN infos: > >http://www.suse.de/~garloff/linux/FreeSWAN/ > >with specific rpm-packages for the variuos SuSE versions. > >HTH, Philipp > >J J schrieb: > > > Are you sure? > > > > According to the /etc/protocols file there is no protocol 500 - the IP > > protocols go no higher than 255. > > > > That makes sense really seeing as the protocol field in IPV4 is only 8 >bits > > long! > > (http://www.ietf.org/rfc/rfc0791.txt) > > > > This is an extract from my current /etc/sysconfig/SuSEfirewall2... > > > > FW_QUICKMODE="no" > > FW_DEV_EXT="ppp0" > > FW_DEV_INT="eth0 ipsec0" > > FW_DEV_DMZ="" > > FW_ROUTE="no" > > FW_MASQUERADE="no" > > FW_MASQ_DEV="$FW_DEV_EXT" > > FW_MASQ_NETS="" > > FW_PROTECT_FROM_INTERNAL="no" > > FW_AUTOPROTECT_SERVICES="yes" > > FW_SERVICES_EXT_TCP="smtp ssh" > > FW_SERVICES_EXT_UDP="isakmp" > > FW_SERVICES_EXT_IP="esp ah" > > > > Anyway I made a small amount of extra progress, at least in the way of > > ruling out problems. I decided to try connecting from the "jellybean" > > gateway itself to the "Bookman" LAN by creating adjusted entries in > > ipsec.conf and succeeded. Basically it worked right out of the box, I >just > > removed the leftsubnet declarations on both sides - now the gateway can >ping > > all the servers on the "Bookman" LAN and vice versa. This isn't the >long > > term solution but does at least show that the boxes will talk to each >other > > and send ipsec traffic correctly. > > > > Plus I toyed with the latest rdesktop and maybe I can persuade people to >use > > that instead of Win 2k boxes with MSTSC client anyway! :) (ha!) > > > > But I'm still not sure why the SuSE 8.2 box is misbehaving and dropping >my > > packets. Do you have any idea how I switch on debugging on the kernel > > routing code?? > > > > >From: Philipp Rusch <Philipp.Rusch(a)rusch-edv.de> > > >To: J J <c_peto(a)hotmail.com> > > >CC: "suse-security(a)suse.com" <suse-security(a)suse.com> > > >Subject: Re: [suse-security] packets still seem to be dropped not >routed > > >despite rp_filter=0 > > >Date: Thu, 11 Sep 2003 20:05:34 +0200 > > > > > >Hi Carl, > > >You are victim of a very common misunderstanding concerning IPSEC > > >and the setup of the firewall .... ;-) > > > > > >Not PORT 500 is needed to setup the tunnel (after negotiation of SA has > > >been > > >done), but PROTOCOL (!!!) 500, which you have to put in the firewall > > >to be allowed through interface ipsec0 (add this to FW_DEV_EXT). > > >Since I do not use SuSE firewall anymore (there are better scripts for > > >iptables) > > >I am not a 100% sure, but I remember that you have to set this in > > >SuSEfirewall2-file as variable FW_SERVICES_EXT_IP = 500. > > > > > >HTH, Philipp > > > > > >J J schrieb: > > > > > > > I'm trying to set up a VPN from "home" LAN to "bookman" LAN. > > > > I've set up Freeswan successfully and it *appears* to be doing it's >job > > >but > > > > still packets aren't getting through. I suspect that routing isn't > > >working > > > > for > > > > some reason and I've reached the limit of my security knowledge. > > > > > > > > Can anyone help? > > > > > > > > The set up is this: > > > > "Bookman" LAN is subnet 192.168.0.0/24 with Ipsec gateway "flanger" >on > > > > IP address 192.168.0.127. "Bookman" LAN connects to internet via >ADSL > > > > ("Vigor") > > > > router that has "Ipsec passthru". In terms of configuration this >means > > >that > > > > I've switched off the "Vigor" router's built-in Ipsec processing and >set > > >UDP > > > > on port 500 to forward direct to "flanger" on 192.168.0.127. The > > >router's > > > > software is set to recognize this combination as a signal to switch >on > > >Ipsec > > > > passthru so that protocols 50 and 51 are also forwarded to the same > > >internal > > > > box. > > > > > > > > (We've successfully set up and used an SA to a "Fortigate" router >based > > >on > > > > this > > > > through to another company "SGPM" and we use that VPN for production > > > > purposes. > > > > It's fast and stable and has impressed management!) > > > > > > > > "Home" LAN is subnet 192.168.10.0/24 with Ipsec gateway "jellybean" >on > > > > external > > > > IP address 217.... (hidden for privacy - if that's me being silly >I'm > > >happy > > > > to > > > > reveal it!). The "home" gateway has an ethernet card on >192.168.10.1 > > >with a > > > > hub connected to that and (at present) one test laptop connected to >the > > >hub > > > > running Win 2k. > > > > > > > > Ipsec gateway on "Bookman" LAN ("flanger") is running SuSE 7.2 and >our > > > > gateway > > > > here ("jellybean") is running SuSE 8.2 (these seem to be Freeswan >1.91 > > >and > > > > 1.99 > > > > respectively). > > > > > > > > The idea is to have a VPN connecting PCs and laptops on the "home" >LAN > > >to > > > > the > > > > servers on the "Bookman" LAN in production. > > > > > > > > Progress so far: > > > > With a small amount of tinkering I managed to get the two pluto >daemons > > >to > > > > talk > > > > and agree an SA but was unable to ping servers on the "Bookman" LAN >from > > > > either our gateway or our test laptop. After help from Rob Maurizzi >on > > >this > > > > mailing list I managed to get KLIPS debugging and found that, rather > > > > boringly, > > > > the gateway was unable to ping Bookman servers because packets were > > >being > > > > seen > > > > by KLIPS as coming from the WAN address of the router (217....) and >so > > >had > > > > no > > > > eroute and were dropped - this was clearly visible in the stats on > > >ifconfig, > > > > which helped. > > > > > > > > Problem: > > > > However this didn't explain why the laptop couldn't reach the >Bookman > > >LAN. > > > > My > > > > initial thought was that routing needed to be switched on. The box >is > > > > configured as a firewall with a SQUID proxy so the "home" LAN can >access > > >the > > > > www. SuSEfirewall2 is running to prevent malicious attacks but >allow > > >Ipsec > > > > traffic. Config is basically - allow external TCP service "ssh" >plus > > > > external > > > > UDP service "isakmp" plus external IP protocols "ah" and "esp", do >not > > > > protect > > > > from internal network, reject rather than drop packets (temporary >for > > >debug) > > > > and log all dropped packets (temporary for debug). > > > > > > > > When I ping from the Win 2k laptop to a Bookman server I see nothing >in > > >the > > > > firewall logs, nothing in KLIPS debug. I see packets arriving on >eth0 > > >but > > > > nothing on ipsec0 or ppp0 (the WAN interface). > > > > > > > > echo "1" > /proc/sys/net/ipv4/ip_forward makes no difference > > > > > > > > cat /proc/sys/net/ipv4/conf/*/forwarding gives "1"s for all devices >and > > > > worse > > > > > > > > cat /proc/sys/net/ipv4/conf/*/rp_filter gives "0"s for all devices! > > > > > > > > Outputs:jellybean:~ # rcipsec start > > > > ipsec_setup: Starting FreeS/WAN IPsec 1.99... > > > > ipsec_setup: ipsec > > > > ipsec_setup: > > > > done > > > > jellybean:~ # ipsec auto --up jellybean-bookman > > > > 104 "jellybean-bookman" #1: STATE_MAIN_I1: initiate > > > > 106 "jellybean-bookman" #1: STATE_MAIN_I2: sent MI2, expecting MR2 > > > > 108 "jellybean-bookman" #1: STATE_MAIN_I3: sent MI3, expecting MR3 > > > > 004 "jellybean-bookman" #1: STATE_MAIN_I4: ISAKMP SA established > > > > 112 "jellybean-bookman" #2: STATE_QUICK_I1: initiate > > > > 004 "jellybean-bookman" #2: STATE_QUICK_I2: sent QI2, IPsec SA > > >established > > > > jellybean:~ # ip route ls > > > > 213.123.101.97 dev ppp0 proto kernel scope link src >217.24.128.146 > > > > 213.123.101.97 dev ipsec0 proto kernel scope link src >217.24.128.146 > > > > 192.168.0.0/24 via 213.123.101.97 dev ipsec0 > > > > 192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.1 > > > > default via 213.123.101.97 dev ppp0 > > > > jellybean:~ # ip rule ls > > > > 0: from all lookup local > > > > 32766: from all lookup main > > > > 32767: from all lookup default > > > > jellybean:~ # route -n > > > > Kernel IP routing table > > > > Destination Gateway Genmask Flags Metric Ref >Use > > > > Iface > > > > 213.123.101.97 0.0.0.0 255.255.255.255 UH 0 0 > 0 > > >ppp0 > > > > 213.123.101.97 0.0.0.0 255.255.255.255 UH 0 0 > 0 > > > > ipsec0 > > > > 192.168.0.0 213.123.101.97 255.255.255.0 UG 0 0 > 0 > > > > ipsec0 > > > > 192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 > 0 > > >eth0 > > > > 0.0.0.0 213.123.101.97 0.0.0.0 UG 0 0 > 0 > > >ppp0 > > > > jellybean:~ # > > > > jellybean:~ # ifconfig > > > > eth0 Link encap:Ethernet HWaddr 00:40:95:30:5C:79 > > > > inet addr:192.168.10.1 Bcast:192.168.10.255 > > >Mask:255.255.255.0 > > > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > > > > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > > > > TX packets:53 errors:0 dropped:0 overruns:0 carrier:0 > > > > collisions:0 txqueuelen:100 > > > > RX bytes:0 (0.0 b) TX bytes:8692 (8.4 Kb) > > > > Interrupt:5 Base address:0xc000 > > > > > > > > ipsec0 Link encap:IPIP Tunnel HWaddr > > > > inet addr:217.24.128.146 Mask:255.255.255.255 > > > > UP RUNNING NOARP MTU:16260 Metric:1 > > > > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > > > > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > > > > collisions:0 txqueuelen:10 > > > > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) > > > > > > > > lo Link encap:Local Loopback > > > > inet addr:127.0.0.1 Mask:255.0.0.0 > > > > UP LOOPBACK RUNNING MTU:16436 Metric:1 > > > > RX packets:32 errors:0 dropped:0 overruns:0 frame:0 > > > > TX packets:32 errors:0 dropped:0 overruns:0 carrier:0 > > > > collisions:0 txqueuelen:0 > > > > RX bytes:2056 (2.0 Kb) TX bytes:2056 (2.0 Kb) > > > > > > > > ppp0 Link encap:Point-to-Point Protocol > > > > inet addr:217.24.128.146 P-t-P:213.123.101.97 > > > > Mask:255.255.255.255 > > > > UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 > > > > RX packets:886 errors:0 dropped:0 overruns:0 frame:0 > > > > TX packets:957 errors:0 dropped:0 overruns:0 carrier:0 > > > > collisions:0 txqueuelen:3 > > > > RX bytes:375562 (366.7 Kb) TX bytes:107243 (104.7 Kb) > > > > > > > > jellybean:~ # > > > > > > > > (OK so I capitulated - u can see my wan address - hey, I trust > > >SuSEfirewall2 > > > > !! :) ) > > > > (Note eth0 stats aren't accurate at the moment, i just created this > > >quickly > > > > before > > > > rushing to a meeting.) > > > > > > > > Does anyone know what happened to my packets?!? > > > > > > > > Regards, > > > > Carl > > > > > > > > _________________________________________________________________ > > > > Tired of 56k? Get a FREE BT Broadband connection > > > > http://www.msn.co.uk/specials/btbroadband > > > > > > > > -- > > > > Check the headers for your unsubscription address > > > > For additional commands, e-mail: suse-security-help(a)suse.com > > > > Security-related bug reports go to security(a)suse.de, not here > > > > > > > _________________________________________________________________ > > Hotmail messages direct to your mobile phone >http://www.msn.co.uk/msnmobile > > > > -- > > Check the headers for your unsubscription address > > For additional commands, e-mail: suse-security-help(a)suse.com > > Security-related bug reports go to security(a)suse.de, not here > _________________________________________________________________ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger

2 1

SuSEfirewall2 and Reverse Masq HELP !
by Chris de Orla 15 Sep '03

15 Sep '03

I want to reverse masquerade on port 25 from the internet to a DMZ address. The problem is when I reverse masquerade to the DMZ, it appears to connect (SuSE-FW-ACCEPT-REVERSE-MASQ) but nothing happens (there is a postfix box running on the DMZ). If I make the reverse-masq to something on the internal network, it connects no problem, anything on the DMZ does not and no failures in syslog. What am I missing here ? I am running SuSE 7.3 and iptables 1.2.8 Below is my firewall2.rc.config : FW_DEV_EXT="eth1" FW_DEV_INT="eth0" FW_DEV_DMZ="eth2" FW_ROUTE="yes" FW_MASQUERADE="yes" FW_MASQ_DEV="$FW_DEV_EXT" FW_MASQ_NETS="xxx.xx.x.x/24" FW_PROTECT_FROM_INTERNAL="yes" FW_AUTOPROTECT_SERVICES="yes" FW_SERVICES_EXT_TCP="123 25" FW_SERVICES_EXT_UDP="123" FW_SERVICES_EXT_IP="" FW_SERVICES_DMZ_TCP="25" FW_SERVICES_DMZ_UDP="" FW_SERVICES_DMZ_IP="" FW_SERVICES_INT_TCP="22 123 25 10000" FW_SERVICES_INT_UDP="123" FW_SERVICES_INT_IP=""FW_TRUSTED_NETS="xxx.xx.x.x/24" FW_ALLOW_INCOMING_HIGHPORTS_TCP="yes" FW_ALLOW_INCOMING_HIGHPORTS_UDP="yes" FW_SERVICE_AUTODETECT="yes" FW_SERVICE_DNS="no" FW_SERVICE_DHCLIENT="no" FW_SERVICE_DHCPD="no" FW_SERVICE_SQUID="no" FW_SERVICE_SAMBA="no" FW_FORWARD="" FW_FORWARD_MASQ="0/0,y.y.y.y,tcp,25" FW_REDIRECT="" FW_LOG_DROP_CRIT="yes" FW_LOG_DROP_ALL="yes" FW_LOG_ACCEPT_CRIT="yes" FW_LOG_ACCEPT_ALL="no" FW_LOG="--log-level warning --log-tcp-options --log-ip-option --log-prefix SuSE-FW" FW_KERNEL_SECURITY="yes" FW_STOP_KEEP_ROUTING_STATE="yes" FW_ALLOW_PING_FW="yes" FW_ALLOW_PING_DMZ="yes" FW_ALLOW_PING_EXT="no" FW_ALLOW_PING_INT="yes" # END of rc.firewall # # #-------------------------------------------------------------------------# # # # EXPERT OPTIONS - all others please don't change these! # # # #-------------------------------------------------------------------------# # # # # 20.) # Allow (or don't) ICMP time-to-live-exceeded to be send from your firewall. # This is used for traceroutes to your firewall (or traceroute like tools). # # Please note that the unix traceroute only works if you say "yes" to # FW_ALLOW_INCOMING_HIGHPORTS_UDP, and windows traceroutes only if you say # additionally "yes" to FW_ALLOW_PING_FW # # Choice: "yes" or "no", defaults to "no" # FW_ALLOW_FW_TRACEROUTE="yes" # # 21.) # Allow ICMP sourcequench from your ISP? # # If set to yes, the firewall will notice when connection is choking, however # this opens yourself to a denial of service attack. Choose your poison. # # Choice: "yes" or "no", defaults to "yes" # FW_ALLOW_FW_SOURCEQUENCH="yes" # # 22.) # Allow/Ignore IP Broadcasts? # # If set to yes, the firewall will not filter broadcasts by default. # This is needed e.g. for Netbios/Samba, RIP, OSPF where the broadcast # option is used. # If you do not want to allow them however ignore the annoying log entries, # set FW_IGNORE_FW_BROADCAST to yes. # # Choice: "yes" or "no", defaults to "no" # FW_ALLOW_FW_BROADCAST="no" # FW_IGNORE_FW_BROADCAST="yes" # # 23.) # Allow same class routing per default? # REQUIRES: FW_ROUTE # # Do you want to allow routing between interfaces of the same class # (e.g. between all internet interfaces, or all internal network interfaces) # be default (so without the need setting up FW_FORWARD definitions)? # # Choice: "yes" or "no", defaults to "no" # FW_ALLOW_CLASS_ROUTING="yes"

2 1

Patching Pine
by remote 15 Sep '03

15 Sep '03

Hi ! I just read about the security announcement SuSE-SA:2003:037 which advises to update Pine because of a security flaw in older versions. I downloaded the patch (pine-4.44-281.i386.patch.rpm) from the SuSE website and installed it as described there. However, after launching Pine, it still showed version number 4.44. Is this correct ? In the announcement it says that there is no workaround for older versions how come I still have the same version number ? Another, maybe dumb, question : what is the difference between the files pine-4.44-281.i386.patch.rpm and pine-4.44-281.i386.rpm ? They are almost of equal size. Thanks, Jörg

4 3

Firewall will not permit local machines to access SQL server in DMZ
by Fred Gemmell 14 Sep '03

14 Sep '03

Hi I have an Alcatel 'frog' USB ADSL modem running off a SuSE linux box configured as a firewall. This machine has 2 network cards. One card is connected directly to a second linux box using a crossover cable, this section being designated as the DMZ. The second linux box runs Apache and MySQL. The other card is connected to an 8 way hub permitting my household network to access the world via the firewall. The gateway (firewall) machine additionally runs Squid http proxy but all the internal user machines are in fact masqueraded onto the Internet. The web server is reverse masqueraded onto the internet, this permits the redirection of incoming http requests (since my ISP blocks port 80) from the port to which they are directed by my dynamic IP address service. Both the linux boxes run without monitors and I administer them remotely using Putty and ssh from one of my user machines. All the user machines run Win XP and communicate with each other using their native peer-to-peer facilities, there being no domain, although Bind is running on the gateway to provide local DNS resolution. When my current contract expires I will move to another provider and obtain a static IP address, at which point I will introduce a domain server. You may wonder why I need all this stuff in my home. So do I. All I can say is: insanity is hereditary, you get it from your kids. I need to access the SQL server from one of my user machines using Microsoft Access, but I cannot figure out how to persuade SuSEfirewall2 to permit this. I know I have a problem with MySQL as the connection still fails when the firewall is turned off, but I can tell from the error logging that communication is not passing the firewall when it is turned on. I can probably figure out the MySQL problem once I can communicate with the machine, but obviously I don't want to leave the firewall turned off. MySQL uses a port in the 3000 range, and I have turned on the 'allow high ports' option in the firewall, but this makes no difference. Can anybody help? Any other comments on the arrangement and security of my system would be appreciated. Fred

3 2

Fw: [UNIX] Buffer Overflow in MySQL (PASSWORD)]
by Radu Voicu 14 Sep '03

14 Sep '03

Hi! Will SuSE update all its previous MySQL packages delivered with the SuSE distributions to 4.0.15? Regards, Radu > > > The following security advisory is sent to the securiteam mailing list, > and can be found at the SecuriTeam web site: http://www.securiteam.com > - - promotion > > The SecuriTeam alerts list - Free, Accurate, Independent. > > Get your security news from a reliable source. > http://www.securiteam.com/mailinglist.html > > - - - - - - - - - > > > > Buffer Overflow in MySQL (PASSWORD) > ------------------------------------------------------------------------ > > > SUMMARY > > <http://www.mysql.com/> MySQL is "the world's most popular open source > database, recognized for its speed and reliability. Today MySQL is the > most popular open source database server in the world with more than 4 > million installations powering websites, datawarehouses, business > applications, logging systems and more". > > Passwords of MySQL users are stored in the "User" table, part of the > "mysql" database, specifically in the "Password" field. > > In MySQL 4.0.x and 3.23.x, these passwords are hashed and stored as a 16 > characters long hexadecimal value, specifically in the "Password" field. > Unfortunately, a function involved in password checking misses correct > bounds checking. By filling a "Password" field a value wider than 16 > characters, a buffer overflow will occur. > > DETAILS > > Vulnerable Systems: > * All versions of MySQL up to and including 4.0.14 > * All versions of MySQL up to and including 3.0.57 > * MySQL version 3.23.51 > > Immune systems: > * MySQL version 4.0.15 > > Anyone with global administrative privileges on a MySQL server may execute > arbitrary code even on a host he is not supposed to have a shell on, with > the privileges of the system account running the MySQL server. > > The get_salt_from_password() function defined in sql/password.c takes an > arbitrary long hex password and returns an arbitrary long binary array > with the previous decoded values : > > void get_salt_from_password(ulong *res,const char *password) > { > res[0]=res[1]=0; > if (password) > { > while (*password) > { > ulong val=0; > uint i; > for (i=0 ; i < 8 ; i++) > val=(val << 4)+char_val(*password++); > *res++=val; > } > } > return; > } > > This function is called sql/sql_acl.cc to check for access control. It is > passed the raw content of the Password field from the User table of the > MySQL database. > > The process aborts if then length is not a multiple of 8 but this is the > only check before get_salt_from_password() is actually called. The > overflow occurs on a local ACL_USER instance in acl_init() and successful > exploitation of that bug is trivial on some platforms. On most Linux > systems, the return address needs about 444 bytes to be overwritten. > > PoC: > > USE mysql; > > ALTER TABLE User CHANGE COLUMN Password Password LONGTEXT; > > UPDATE User SET Password = > '123456781234567812345678123456781234567812345678123456781234567812345678 > 123456781234567812345678123456781234567812345678123456781234567812345678 > 123456781234567812345678123456781234567812345678123456781234567812345678 > 12345678123456781234567812345678...' WHERE User = 'abcd'; > > FLUSH PRIVILEGES; > > > [Connection lost] > mysqld_safe/safe_mysqld log : > > 030806 21:05:43 mysqld restarted > 030806 21:05:43 mysqld restarted > 030806 21:05:43 mysqld restarted > 030806 21:05:43 mysqld restarted > > MySQL log : tons of > > mysqld got signal 11; > This could be because you hit a bug. It is also possible that this binary > or one of the libraries it was linked against is corrupt, improperly > built, or mis-configured. This error can also be caused by malfunctioning > hardware. We will try our best to scrape up some info that will hopefully > help diagnose the problem, but since we have already crashed, something is > definitely wrong > > Vendor Status: > MySQL AB has been informed of this vulnerability on Wed, 6 Aug 2003. The > issue was confirmed and fixed in the development tree the next day. > > MySQL 4.0.15, which includes a fix for this vulnerability and other > unrelated bugs, is now available for download from the following location: > <http://www.mysql.com/downloads/mysql-4.0.html> > http://www.mysql.com/downloads/mysql-4.0.html > > Unofficial patch: > The following patch (applies fine to 4.0.14, should also work on earlier > releases with minor fuzz) fixes the bug: > > --- mysql-4.0.14-old/sql/sql_acl.cc 2003-07-18 16:57:25.000000000 +0200 > +++ mysql-4.0.14/sql/sql_acl.cc 2003-09-10 23:21:13.559759576 +0200 > @@ -233,7 +233,7 @@ > "Found old style password for user '%s'. Ignoring user. (You may want > to restart mysqld using --old-protocol)", > user.user ? user.user : ""); /* purecov: tested */ > } > - else if (length % 8) // This holds true for passwords > + else if (length % 8 || length > 16) // This holds true for passwords > { > sql_print_error( > "Found invalid password for user: '%s@%s'; Ignoring user", > > > ADDITIONAL INFORMATION > > The information has been provided by <mailto:j@42-Networks.Com> Frank > DENIS (Jedi/Sector One) > > > > ======================================== > > > This bulletin is sent to members of the SecuriTeam mailing list. > To unsubscribe from the list, send mail with an empty subject line and > body to: list-unsubscribe(a)securiteam.com > In order to subscribe to the mailing list, simply forward this email to: > list-subscribe(a)securiteam.com > > > ==================== > ==================== > > DISCLAIMER: > The information in this bulletin is provided "AS IS" without warranty of > any kind. > In no event shall we be liable for any damages whatsoever including > direct, indirect, incidental, consequential, loss of business profits or > special damages. > > > > > > >

2 1

Chris Mason's bouncer
by Volker Kuhlmann 14 Sep '03

14 Sep '03

Chris Mason made a tool which can tunnel tcp over an https proxy. It's reputably very good, but all I can find is links to r00t3d.org.uk, which isn't even registered now. Versions were at least up to Bouncer v1.0.RC6. Would someone have a copy stashed away somewhere? Thanks much, Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.

1 0

Automatically Updating named (bind9) with local address translations
by Philip B Cook 13 Sep '03

13 Sep '03

I am successfully using SuSE Linux as a gateway, router and http proxy. I am connected to the internet via a Cable Modem. The Linux machine is running Squid, SuSEfirewall2, dhcpcd and Samba (smbd and nmbd). My local machines get their IP addresses from the dhcpcd server, these are allocated dynamically. DHCPCD tells each machine to use the Cable Companies two DNS servers for name resolution. I would like to use named (BIND9) to provide a local cache of internet addresses, which is easy, but how can I also provide name resolution for each of the local machines from BIND9 without having to use static IP addresses on my local network or use fixed addressing for each MAC address in DHCPD. Once a local machine gets an IP address from DHCPCD can this information be given to BIND9 so that it will do local lookups as well as caching internet addresses. Can this be done by either the server or the hosts. Thanks ... Philip

1 0

SuSE lists SPAM
by Radu Voicu 12 Sep '03

12 Sep '03

Hi! I was wondering, why on the SuSE Lists archives people can find our EXACT e-mail adress??? A simple scan of the messages on that page will return our real e-mail addresses - there's only one step away from "enlarge your penis" or "rich nigerians" e-mails... Please, SuSE people, can you do something to transform our e-mail addresses on the archives (remove them, if you cannot transform them into, for instance, suse at ploiesti dot rdsnet dot ro - instead of showing suse(a)ploiesti.rdsnet.ro) Best regards, Radu Voicu

5 6

IpSec
by Andrew Edunov 12 Sep '03

12 Sep '03

hi All!!! I install freeswan-1.98_0.9.14-72 on SuSE 8.1 k_deflt-2.4.19-274. Vpn works fine. But when I try to do: tcpdump -qni ipsec0 the result is: 12:33:19.995548 unknown ip 0 and I don't undestand why. Is this a bug of ipsec? Or kernel? Please give me advice. -- IT Administrator Andrew Edunov and(a)snq.ru +7 (095) 785-42-82 +7 (095) 785-42-83 8 (903) 610-48-76

1 0

Re: [suse-security] packets still seem to be dropped not routed despite rp_filter=0
by J J 11 Sep '03

11 Sep '03

Are you sure? According to the /etc/protocols file there is no protocol 500 - the IP protocols go no higher than 255. That makes sense really seeing as the protocol field in IPV4 is only 8 bits long! (http://www.ietf.org/rfc/rfc0791.txt) This is an extract from my current /etc/sysconfig/SuSEfirewall2... FW_QUICKMODE="no" FW_DEV_EXT="ppp0" FW_DEV_INT="eth0 ipsec0" FW_DEV_DMZ="" FW_ROUTE="no" FW_MASQUERADE="no" FW_MASQ_DEV="$FW_DEV_EXT" FW_MASQ_NETS="" FW_PROTECT_FROM_INTERNAL="no" FW_AUTOPROTECT_SERVICES="yes" FW_SERVICES_EXT_TCP="smtp ssh" FW_SERVICES_EXT_UDP="isakmp" FW_SERVICES_EXT_IP="esp ah" Anyway I made a small amount of extra progress, at least in the way of ruling out problems. I decided to try connecting from the "jellybean" gateway itself to the "Bookman" LAN by creating adjusted entries in ipsec.conf and succeeded. Basically it worked right out of the box, I just removed the leftsubnet declarations on both sides - now the gateway can ping all the servers on the "Bookman" LAN and vice versa. This isn't the long term solution but does at least show that the boxes will talk to each other and send ipsec traffic correctly. Plus I toyed with the latest rdesktop and maybe I can persuade people to use that instead of Win 2k boxes with MSTSC client anyway! :) (ha!) But I'm still not sure why the SuSE 8.2 box is misbehaving and dropping my packets. Do you have any idea how I switch on debugging on the kernel routing code?? >From: Philipp Rusch <Philipp.Rusch(a)rusch-edv.de> >To: J J <c_peto(a)hotmail.com> >CC: "suse-security(a)suse.com" <suse-security(a)suse.com> >Subject: Re: [suse-security] packets still seem to be dropped not routed >despite rp_filter=0 >Date: Thu, 11 Sep 2003 20:05:34 +0200 > >Hi Carl, >You are victim of a very common misunderstanding concerning IPSEC >and the setup of the firewall .... ;-) > >Not PORT 500 is needed to setup the tunnel (after negotiation of SA has >been >done), but PROTOCOL (!!!) 500, which you have to put in the firewall >to be allowed through interface ipsec0 (add this to FW_DEV_EXT). >Since I do not use SuSE firewall anymore (there are better scripts for >iptables) >I am not a 100% sure, but I remember that you have to set this in >SuSEfirewall2-file as variable FW_SERVICES_EXT_IP = 500. > >HTH, Philipp > >J J schrieb: > > > I'm trying to set up a VPN from "home" LAN to "bookman" LAN. > > I've set up Freeswan successfully and it *appears* to be doing it's job >but > > still packets aren't getting through. I suspect that routing isn't >working > > for > > some reason and I've reached the limit of my security knowledge. > > > > Can anyone help? > > > > The set up is this: > > "Bookman" LAN is subnet 192.168.0.0/24 with Ipsec gateway "flanger" on > > IP address 192.168.0.127. "Bookman" LAN connects to internet via ADSL > > ("Vigor") > > router that has "Ipsec passthru". In terms of configuration this means >that > > I've switched off the "Vigor" router's built-in Ipsec processing and set >UDP > > on port 500 to forward direct to "flanger" on 192.168.0.127. The >router's > > software is set to recognize this combination as a signal to switch on >Ipsec > > passthru so that protocols 50 and 51 are also forwarded to the same >internal > > box. > > > > (We've successfully set up and used an SA to a "Fortigate" router based >on > > this > > through to another company "SGPM" and we use that VPN for production > > purposes. > > It's fast and stable and has impressed management!) > > > > "Home" LAN is subnet 192.168.10.0/24 with Ipsec gateway "jellybean" on > > external > > IP address 217.... (hidden for privacy - if that's me being silly I'm >happy > > to > > reveal it!). The "home" gateway has an ethernet card on 192.168.10.1 >with a > > hub connected to that and (at present) one test laptop connected to the >hub > > running Win 2k. > > > > Ipsec gateway on "Bookman" LAN ("flanger") is running SuSE 7.2 and our > > gateway > > here ("jellybean") is running SuSE 8.2 (these seem to be Freeswan 1.91 >and > > 1.99 > > respectively). > > > > The idea is to have a VPN connecting PCs and laptops on the "home" LAN >to > > the > > servers on the "Bookman" LAN in production. > > > > Progress so far: > > With a small amount of tinkering I managed to get the two pluto daemons >to > > talk > > and agree an SA but was unable to ping servers on the "Bookman" LAN from > > either our gateway or our test laptop. After help from Rob Maurizzi on >this > > mailing list I managed to get KLIPS debugging and found that, rather > > boringly, > > the gateway was unable to ping Bookman servers because packets were >being > > seen > > by KLIPS as coming from the WAN address of the router (217....) and so >had > > no > > eroute and were dropped - this was clearly visible in the stats on >ifconfig, > > which helped. > > > > Problem: > > However this didn't explain why the laptop couldn't reach the Bookman >LAN. > > My > > initial thought was that routing needed to be switched on. The box is > > configured as a firewall with a SQUID proxy so the "home" LAN can access >the > > www. SuSEfirewall2 is running to prevent malicious attacks but allow >Ipsec > > traffic. Config is basically - allow external TCP service "ssh" plus > > external > > UDP service "isakmp" plus external IP protocols "ah" and "esp", do not > > protect > > from internal network, reject rather than drop packets (temporary for >debug) > > and log all dropped packets (temporary for debug). > > > > When I ping from the Win 2k laptop to a Bookman server I see nothing in >the > > firewall logs, nothing in KLIPS debug. I see packets arriving on eth0 >but > > nothing on ipsec0 or ppp0 (the WAN interface). > > > > echo "1" > /proc/sys/net/ipv4/ip_forward makes no difference > > > > cat /proc/sys/net/ipv4/conf/*/forwarding gives "1"s for all devices and > > worse > > > > cat /proc/sys/net/ipv4/conf/*/rp_filter gives "0"s for all devices! > > > > Outputs:jellybean:~ # rcipsec start > > ipsec_setup: Starting FreeS/WAN IPsec 1.99... > > ipsec_setup: ipsec > > ipsec_setup: > > done > > jellybean:~ # ipsec auto --up jellybean-bookman > > 104 "jellybean-bookman" #1: STATE_MAIN_I1: initiate > > 106 "jellybean-bookman" #1: STATE_MAIN_I2: sent MI2, expecting MR2 > > 108 "jellybean-bookman" #1: STATE_MAIN_I3: sent MI3, expecting MR3 > > 004 "jellybean-bookman" #1: STATE_MAIN_I4: ISAKMP SA established > > 112 "jellybean-bookman" #2: STATE_QUICK_I1: initiate > > 004 "jellybean-bookman" #2: STATE_QUICK_I2: sent QI2, IPsec SA >established > > jellybean:~ # ip route ls > > 213.123.101.97 dev ppp0 proto kernel scope link src 217.24.128.146 > > 213.123.101.97 dev ipsec0 proto kernel scope link src 217.24.128.146 > > 192.168.0.0/24 via 213.123.101.97 dev ipsec0 > > 192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.1 > > default via 213.123.101.97 dev ppp0 > > jellybean:~ # ip rule ls > > 0: from all lookup local > > 32766: from all lookup main > > 32767: from all lookup default > > jellybean:~ # route -n > > Kernel IP routing table > > Destination Gateway Genmask Flags Metric Ref Use > > Iface > > 213.123.101.97 0.0.0.0 255.255.255.255 UH 0 0 0 >ppp0 > > 213.123.101.97 0.0.0.0 255.255.255.255 UH 0 0 0 > > ipsec0 > > 192.168.0.0 213.123.101.97 255.255.255.0 UG 0 0 0 > > ipsec0 > > 192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 >eth0 > > 0.0.0.0 213.123.101.97 0.0.0.0 UG 0 0 0 >ppp0 > > jellybean:~ # > > jellybean:~ # ifconfig > > eth0 Link encap:Ethernet HWaddr 00:40:95:30:5C:79 > > inet addr:192.168.10.1 Bcast:192.168.10.255 >Mask:255.255.255.0 > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > > TX packets:53 errors:0 dropped:0 overruns:0 carrier:0 > > collisions:0 txqueuelen:100 > > RX bytes:0 (0.0 b) TX bytes:8692 (8.4 Kb) > > Interrupt:5 Base address:0xc000 > > > > ipsec0 Link encap:IPIP Tunnel HWaddr > > inet addr:217.24.128.146 Mask:255.255.255.255 > > UP RUNNING NOARP MTU:16260 Metric:1 > > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > > collisions:0 txqueuelen:10 > > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) > > > > lo Link encap:Local Loopback > > inet addr:127.0.0.1 Mask:255.0.0.0 > > UP LOOPBACK RUNNING MTU:16436 Metric:1 > > RX packets:32 errors:0 dropped:0 overruns:0 frame:0 > > TX packets:32 errors:0 dropped:0 overruns:0 carrier:0 > > collisions:0 txqueuelen:0 > > RX bytes:2056 (2.0 Kb) TX bytes:2056 (2.0 Kb) > > > > ppp0 Link encap:Point-to-Point Protocol > > inet addr:217.24.128.146 P-t-P:213.123.101.97 > > Mask:255.255.255.255 > > UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 > > RX packets:886 errors:0 dropped:0 overruns:0 frame:0 > > TX packets:957 errors:0 dropped:0 overruns:0 carrier:0 > > collisions:0 txqueuelen:3 > > RX bytes:375562 (366.7 Kb) TX bytes:107243 (104.7 Kb) > > > > jellybean:~ # > > > > (OK so I capitulated - u can see my wan address - hey, I trust >SuSEfirewall2 > > !! :) ) > > (Note eth0 stats aren't accurate at the moment, i just created this >quickly > > before > > rushing to a meeting.) > > > > Does anyone know what happened to my packets?!? > > > > Regards, > > Carl > > > > _________________________________________________________________ > > Tired of 56k? Get a FREE BT Broadband connection > > http://www.msn.co.uk/specials/btbroadband > > > > -- > > Check the headers for your unsubscription address > > For additional commands, e-mail: suse-security-help(a)suse.com > > Security-related bug reports go to security(a)suse.de, not here > _________________________________________________________________ Hotmail messages direct to your mobile phone http://www.msn.co.uk/msnmobile

2 2