Thank you. My fast Internet provider is Comcast ( http://www.comcast.net/chsi.html ). My internet connection is through the TV cable. Most of the times I run as user "mauede" ...very raraely I need to turn to "root" .. I do that if I need to install/uninstall something. My browser is Netscape 7.2 which occasionally marks as SPAM messages that I get ... but I haven't found out yet which criteria it uses to do so. In fact it calls spam what actually is importatnt to me. My Internet provider does have anti-virus and anyi-spam products that can be downloaded for free but they are specific for Windows. Sorry for my ignorance ... what is a "a rootkit hunter" ????? Regards, Maura peter Nikolic wrote:

On Sunday 03 Oct 2004 05:40, Maura Edelweiss Monville wrote:

...

It's well known that Linux is not affected by any of the viruses that catch Windows as soon as the computer is turned on ... Nevertheless Linux is affected by spyware. My computer is unfortunately a victim of this form of advertising although I've been running SuSE since I bought it 3 years ago. I'd appreciate some help to get rid of these parasitic processes dwelling in my computer. Thank you in advance.

MEM

Well now there's a first .

I have been running Suse since 5.2 solidly with no Spyware or anything problems .

What are you getting what browser are you using what is your internet connection who is your ISP what are you running as ie root or user ..?..

There are some extreemley annoying adds on some web pages that pop up new windows well you can stop those in your browser .

Do NOT blindley accept coockies i do not care what people claim about them they are a BIG pain in the rear end and site have to beg to get on onto this machine if it ain't from the site i am on then it's good night Vienna no chance , Run a rootkit hunter at regular intervals prefereably from an READ ONLY Source .

<rant>

I have just installed Adblock on my main machine in Mozilla 1.7.3 and it works a treat blocks those ULTRA annoying microslops adverts dead in the water no sites named cus i have just had a run in with one site ( you should have a choice of allowing or not those insults to your senses) i dont care Who pays to place them they should be context sensative(SP) and i dont care who dont like the idea .

</rant>

Pete .

* Sid Boyce [10-03-04 09:53]:

I think there is a RPM available on SuSE, but I built mine from sources and it runs daily, sending mail to me as user so I can see if there is a problem. barrabas:/usr/src/linux-2.6.9-rc3-mm1 # rpm -qi rkhunter Name : rkhunter Relocations: (not relocatable) Version : 1.1.4 Vendor: (none) Release : 1.cjo Build Date: Sun 08 Aug 2004

An rpm build on SuSE.noarch available: http://wahoo.no-ip.org/~pat/rkhunter-1.1.8-1.ps.noarch.rpm latest public version. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/photos

doc wrote:

...

An rpm build on SuSE.noarch available: http://wahoo.no-ip.org/~pat/rkhunter-1.1.8-1.ps.noarch.rpm

Why would the YaST install of rkhunter under SuSE 9.1 generate lukeftp and ftp conflict errors?

Ooops! The conflict is with lukemftp not lukeftp, my clumsy fingers! -- Thanks! & 73, doc kd4e West Central Florida 100% Linux. Suse 9.1 Drake, Hallicrafters, Heathkit, TenTec, Yaesu Radio Life: http://www.gospelcom.net/twr/ Linux-Incompatible hardware is defective! USA Pres. Election 2004: http://www.rnc.org/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

David Krider wrote:

On Sun, 2004-10-03 at 09:53, Sid Boyce wrote:

...

Rootkit scanner is scanning tool to ensure you for about 99.9% you're clean of nasty tools. This tool scans for rootkits, backdoors and local exploits by running tests like:

Seems to me that a better alternative to needing a "scanner" that needs constant updating to keep up with changing "fingerprints," like a virus scanner, would be to install tripwire. It keeps an encrypted database of checksums of all the important files on your system. You need a separate password to change the database. (For example, to update after installing a new package.) Even root needs that password, so a rootkit can't get on your system and mess with the database without you knowing it.

dk

The reason I go with libsafe is that it's preloaded to every binary and is more proactive in stopping the attacks at the point when they try to do damage, it needs no configuration like tripwire to be effective, still too much protection is better than too little. I also use virus scanners, clamav and BitDefender. Regards Sid. -- Sid Boyce .... Hamradio G3VBV and keen Flyer =====LINUX ONLY USED HERE=====

Maura Edelweiss Monville wrote: <STUFF DELETED>

Are the last two s/w packages you mention, namely clamav and BitDefender, specific for Linux platforms ? Where can they be found ? Are they commercial products ? I hope they are all easy to install ... As a graduate student overwhelmed with research issues, I love to install rpm files as it only require one command line .... Whenit comes to installing products that require options set-up then I ususally give up for lacjk of time on reading and documenting myself. Thank you for all your help. Regards, maura

amavis and clamav are available on the SuSE CD's and for download from the ftp site. BitDefender is commercial, but there is a free commandline version for Linux at ftp://ftp.bitdefender.com/pub/linux/free/bitdefender-console/en/BitDefender-Console-Antivirus-7.0.1-3.linux-gcc3x.i586.rpm. Having used Linux since it was first put up for ftp and having installed it and used it on a number of platforms including S390 and SPARC, there are still some package configuration files that deny analysis and some tools like apt4rpm that lack flexibility, so I avoid them. Regards Sid. -- Sid Boyce .... Hamradio G3VBV and keen Flyer =====LINUX ONLY USED HERE=====

(Ted Harding) wrote:

On 03-Oct-04 Maura Edelweiss Monville wrote:

...

[...] Sorry for my ignorance ... what is a "a rootkit hunter" ?????

Regards, Maura

Myself I hadn't even heard of "rootkit" until very recently when someone posted to linux-users@lists.man.ac.uk that he had been infected twice over. In his explanation to me he wrote:

"An apache vulnerability is where carefully crafted information is sent to such a web server, thus overrunning a buffer or such-like, and being able to install and execute arbitrary code.

A rootkit is the stuff script-kiddies (people who use software provided from elsewhere) install on your machine, in an attempt to replace core utilities (ls, find, ps, top, ....) by ones that don't show illicit activity, even when it is taking place. In my case they don't seem to have gained root access, so have been unable to totally screw my machine, but they installed their own telnetd, nmap, stealth scanners and other software.

The main problem is that chkrootkit (www.chkrootkit.org) doesn't scan for these rootkits, since they are not included. It is still worth your while to use chkrootkit!"

So I went to

http://www.chkrootkit.org

and installed chkrootkit anyway! There may be other rootkit-checkers out there which may be preferable. There is a lot of info on this site about how rootkits work.

Some of chkrootkit's tests are a bit dumb, and likely to throw up false positives (which is way better than false negatives!). In particular, any file under /usr/lib/ whose filename begins with a "." will be flagged up. Since these can be created by standard software (e.g. perl, java) they need not be, and probably are not, sinister. But don't take this for granted either!

I hope this helps! Ted.

I've used chkrootkit in the past, a long time since I've seen it, now I use rkhunter-1.1.8-1.noarch.rpm (latest). One thing I have always installed promptly on all distros going back quite a few years right up to (SuSE9.1 x86 and x86_64, Mandrake 10.0 and gentoo-2004-2) is libsafe, http://www.research.avayalabs.com/project/libsafe/, it stops buffer overflows doing nasties, format strings and other attacks. I think only the Brazilian distro (Connectiva) includes it as standard. SuSE was very anti libsafe when it first came out, possibly because at that time it stopped the binary working and resultant complaints may have scared them off, now it is able to let the binary run, but makes sure it doesn't overwrite, negligible performance hit also. From the blurb:- Projects: Libsafe The exploitation of buffer overflow and format string vulnerabilities in process stacks constitutes a significant portion of security attacks in recent years. We present a new method to detect and handle such attacks. In contrast to previous work, our method does not require any modification to the operating system and works with existing binary programs. Our method does not require access to the source code of defective programs, nor does it require recompilation or off-line processing of binaries. Furthermore, it can be implemented on a system-wide basis transparently. Our solution is based on a middleware software layer that intercepts all function calls made to library functions that are known to be vulnerable. A substitute version of the corresponding function implements the original functionality, but in a manner that ensures that any buffer overflows are contained within the current stack frame, thus, preventing attackers from 'smashing' (overwriting) the return address and hijacking the control flow of a running program. barrabas:/ftp/oct04 # ldd /usr/bin/grep /lib/libsafe.so.2 => /lib/libsafe.so.2 (0x40019000) linux-gate.so.1 => (0xffffe000) libc.so.6 => /lib/tls/libc.so.6 (0x40059000) libdl.so.2 => /lib/libdl.so.2 (0x4016e000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Most of the updates to all distros are to do with buffer overflows, so I preempt them with libsafe. Regards Sid. -- Sid Boyce .... Hamradio G3VBV and keen Flyer =====LINUX ONLY USED HERE=====

On Sun, 2004-10-03 at 08:08 -0500, David Krider wrote:

On Sat, 2004-10-02 at 23:40, Maura Edelweiss Monville wrote:

...

Nevertheless Linux is affected by spyware. My computer is unfortunately a victim of this form of advertising although I've been running SuSE since I bought it 3 years ago.

Please. She knows enough to get Linux installed and usable, and knows spyware when she sees it, but can't give us an attack vector? Or even a process name? What I'm saying is that surely a Linux user (of 3 years) knows enough about the situation to recognize a popup saying something to the effect of "your computer has been infected!", which is the only "spyware" problem that Linux has.

I think this is the same sort of thing as the stupid thread on performance problems. What a bunch of FUD.

Please be aware that everybody that use Linux is not a Linux guru. On the one hand there is huge drive to make Linux distro's more user friendly so that the non-computer-savvy user can also use it. SuSE is one of the distro's that have managed to do this. Now that we have a number of normal users who use Linux as thier OS and not thier hobby or job, people frown on them if they don't understand all the intricacies of the system. You can easily install SuSE without knowing how things work in the background. Also, everybody that use a computer does not necessarily know what spyware is or what spam is. Every SuSE user does not read slashdot or any IT-related site. It turned out that Maura has been getting a lot of spam recently and she thought this was because of spyware that were installed on her machine. So, please don't flame everybody that does not know how to compile a kernel or know how the internet work. If we want Linux to effectively make a dent in the desktop world, then we need to cater for users who use Linux as tool to get a job done, like they would use a microwave oven to heat up a TV dinner. Just think quickly for yourself how many people that use a microwave oven know how the machine actually works? Do you learn what a magnatron is before you heat up your TV dinner? -- Andre Truter | Software Engineer | Registered Linux user #185282 ICQ #40935899 | AIM: trusoftzaf | http://www.trusoft.co.za ~ "Oh Bother!" said the Borg, "We assimilated the Pooh!" ~

Please. She knows enough to get Linux installed and usable, and knows spyware when she sees it, but can't give us an attack vector? Or even a process name? What I'm saying is that surely a Linux user (of 3 years) knows enough about the situation to recognize a popup saying something to the effect of "your computer has been infected!", which is the only "spyware" problem that Linux has.

Dang, that's the same spyware I have been getting on my SuSE 9.1 box... Strangest damn thing though, it pops up in a window that looks like Windows!!! :)

On Sunday 03 October 2004 09:46 am, Paul W. Abrahams wrote:

On Sunday 03 October 2004 12:40 am, Maura Edelweiss Monville wrote:

...

It's well known that Linux is not affected by any of the viruses that catch Windows as soon as the computer is turned on ... Nevertheless Linux is affected by spyware. My computer is unfortunately a victim of this form of advertising although I've been running SuSE since I bought it 3 years ago. I'd appreciate some help to get rid of these parasitic processes dwelling in my computer. Thank you in advance.

I'm puzzled by this. So far Linux has not been an attractive target for parasites -- why waste your effort on a system with such a small market share (even though, as we all know, it deserves a far bigger one)? Aren't all those spywares system-specific?

Paul Abrahams

Paul, your question seems to suggest you buy into the Microsoft Myth which claims the only reason Microsoft systems are the target of spyware, worms, and viruses is because Windows is "Popular". There are major qualitative and structural differences between Windows and Linux that Microsoft would like to have you believe don't exist. Unlike windows, drive-by installs of spyware are very difficult in linux and as such would require social engineering to trick the user into stalling them. -- _____________________________________ John Andersen

On Sunday 03 October 2004 05:54 pm, Paul W. Abrahams wrote:

...

There are major qualitative and structural differences between Windows and Linux that Microsoft would like to have you believe don't exist.  

Sure, Linux is harder to break into. but after all, Linux also has its infamous rootkit.  On the principle that better neighborhoods attract a better class of burglers, Linux would attract sufficiently talented hackers if it were in wider use.  

The root kit does nothing unless some other vulnerability is exploited first. Its not like you can do a drive-by install of the root kit, and even if you did install it as a user it only gives you that Users permissions. The point is that Microsoft put that idea into your head that it is only due to popularity that Windows is a target. The truth of the matter is Windows is vulnerable because windows is vulnerable. Its attacked because is is vulnerable and any 13 year old can break in with only a few scripts. -- _____________________________________ John Andersen

...

The truth of the matter is Windows is vulnerable because windows is vulnerable. Its attacked because is is vulnerable and any 13 year old can break in with only a few scripts.

Hey, my kid isn't just "any 13 year old" ;-)

A similar situation occurred with OS/2. Because of the way it was built, it was very difficult for a virus to infect it. About the only way in, was a boot sector virus, which means you had to boot from an infected floppy, to get infected. Viruses are almost entirely a Windows problem, because of inherent deficiencies.

Sadly I miscalulated IBM's ability to market OS/2, so now I'm running 5+ year old software on most of my office desktops, at least until I can finish updating my proprietary software to run on Linux. I've never had a virus or exploit of any kind on any of my OS/2 or Linux boxes. My decision to select reliability and security over popularity has caused me to endure constant hassling by employees who don't want to use anything but Windows (I suspect because it has the best selection of time wasting toys). Nevertheless I've held firm and it looks like I've picked the right pony this time. Jeff

On Monday 04 October 2004 10:09, doc wrote:

...

toys). Nevertheless I've held firm and it looks like I've picked the right pony this time.

There was some speculation on a recent Apple-related online newsletter that Apple should buy Novell and merge OS X with SuSE, though the argument was mostly based on marketing and systems reasons rather than the OS.

Even if that were to happen the adjustment of your apps would be minor given than OS X is built on Unix.

I'm not too worried. I've learned a hard lesson and my new apps are being written in C++ and Qt and will be portable to any popular OS. Jeff

peter Nikolic wrote:

On Monday 04 Oct 2004 02:54, Paul W. Abrahams wrote:

<STUFF DELETED>

...

Sure, Linux is harder to break into. but after all, Linux also has its infamous rootkit. On the principle that better neighborhoods attract a better class of burglers, Linux would attract sufficiently talented hackers if it were in wider use.

Linux, with its underlying foundation of old C code, is particularly vulnerable to buffer-overflow attacks.

Paul

Ever heard of Libsafe .. ?....

worth investigating i dont get problems from buffer overflow attacks thanks to Libsafe it can them before they can cause mischief ..

Pete

Pete, you and I have used libsafe since it was first introduced and make sure it's installed. We know you have to look beyond the stuff in the distro. We also don't buy into the numbers argument, Windows was not designed with security in mind and does nothing to beef up security other than issue patches for the current crop of attacks as they are exposed. Buffer overflow and format string attacks get killed by libsafe (that answers Paul W. Abrahams point above), so the question raised many times, including by lwn.net about three years ago as to why only Connectiva uses it, perhaps not only Microsoft thinks like Microsoft - vulnerability gets exposed, issue a patch to fix it, exposure exists, discover it, fix it, hoping you don't get bitten before the fix comes out - sounds a crazy scheme to me. Regards Sid. -- Sid Boyce .... Hamradio G3VBV and keen Flyer =====LINUX ONLY USED HERE=====

On Monday 04 Oct 2004 12:42, Johan Nielsen wrote:

Mandag den 4. oktober 2004 12:27 skrev Sid Boyce:

...

peter Nikolic wrote:

...

On Monday 04 Oct 2004 02:54, Paul W. Abrahams wrote:

<STUFF DELETED>

...

...

Sure, Linux is harder to break into. but after all, Linux also has its infamous rootkit. On the principle that better neighborhoods attract a better class of burglers, Linux would attract sufficiently talented hackers if it were in wider use.

Linux, with its underlying foundation of old C code, is particularly vulnerable to buffer-overflow attacks.

Paul

Ever heard of Libsafe .. ?....

worth investigating i dont get problems from buffer overflow attacks thanks to Libsafe it can them before they can cause mischief ..

Pete

Silly question for you and Pete. How would you implement "Libsafe" into you Suse distro ??

Secondly other suggestions/"easy" usable pointers to make SuSE a safe place to be ;-)

TIA

Johan

...

Pete, you and I have used libsafe since it was first introduced and make sure it's installed. We know you have to look beyond the stuff in the distro. We also don't buy into the numbers argument, Windows was not designed with security in mind and does nothing to beef up security other than issue patches for the current crop of attacks as they are exposed. Buffer overflow and format string attacks get killed by libsafe (that answers Paul W. Abrahams point above), so the question raised many times, including by lwn.net about three years ago as to why only Connectiva uses it, perhaps not only Microsoft thinks like Microsoft - vulnerability gets exposed, issue a patch to fix it, exposure exists, discover it, fix it, hoping you don't get bitten before the fix comes out - sounds a crazy scheme to me. Regards Sid.

-- Sid Boyce .... Hamradio G3VBV and keen Flyer =====LINUX ONLY USED HERE===== Install ing Libsafe is no big deal .

down load it build it install it .. /etc/libsafe.exclude /lib/libsafe.so.2 /lib/libsafe.so.2.0.16 /usr/share/man/man8/libsafe.8 I have not looked for a while but i would not mind betting there is a newer version around now .. As for making Suse safe as in secure well i am on an ADSL connection so i have an seperate firewall on the network here that seems to keep things pretty tight i have sat and watched the script kiddies play at trying to find a way in none of them has as yet , I keep em guessing by changing things all the time so they very rarely see the same configuration twice. Dont run as root , A good password is important on ALL logins be it root or user and keep it changed but i don't believe in changing the password on a regular intereval keep it random makes it a lot harder to keep track of . If you are dial up or one of the DSL flavours then run BBIagent "http://bbiagent.net" as your connection to the outside world it has a good firewall and is very flexible i have quite a few people using it including a couple of windBloZe users thatbhave never been hacked as yet and they are on 24/7 plus virus scanners of course . Pete . -- Linux user No: 256242 Machine No: 139931 G6NJR Pete also MSA registered "Quinton 11" A Linux Only area Happy bug hunting M$ clan, The time is here to FORGET that M$ Corp ever existed the world does not NEED M$ Corp the world has NO USE for M$ Corp it is time to END M$ Corp , Play time is over folks time for action approaches at an alarming pace the death knell for M$ Copr has been sounded . Termination time is around the corner ..

On Tuesday 05 Oct 2004 02:23, Paul W. Abrahams wrote:

On Monday 04 October 2004 7:23 pm, peter Nikolic wrote:

...

As for making Suse safe as in secure well i am on an ADSL connection so i have an seperate firewall on the network here that seems to keep things pretty tight i have sat and watched the script kiddies play at trying to find a way in none of them has as yet , I keep em guessing by changing

things

...

all the time so they very rarely see the same configuration twice.

That raises an interesting question. Suppose you didn't keep them guessing, and never changed your passwords. Do you think your system would still be safe? I would guess so; if you choose your passwords sensibly and restrict the retry rate for logins to, say, once every five seconds (which would hardly inconvenience an authorized user), it would take many years for anyone to mechanically guess your critical passwords -- by which time you'd probably be running SuSE 18.2. :=)

Paul

Well now there's a good one i think the only valid answer has just gopt to be how knows some little smuck may just get lucky but i doubt it somehow , all i got to do is find a way if it is a windBloZe box that finds a way in is work out a way of doing an fdisk c: on there machine over the net or install dban to run on there next reboot that should be good fun Cheers Pete . -- Linux user No: 256242 Machine No: 139931 G6NJR Pete also MSA registered "Quinton 11" A Linux Only area Happy bug hunting M$ clan, The time is here to FORGET that M$ Corp ever existed the world does not NEED M$ Corp the world has NO USE for M$ Corp it is time to END M$ Corp , Play time is over folks time for action approaches at an alarming pace the death knell for M$ Copr has been sounded . Termination time is around the corner ..

Johan Nielsen wrote:

Mandag den 4. oktober 2004 12:27 skrev Sid Boyce:

...

peter Nikolic wrote:

...

On Monday 04 Oct 2004 02:54, Paul W. Abrahams wrote:

<STUFF DELETED>

...

...

Sure, Linux is harder to break into. but after all, Linux also has its infamous rootkit. On the principle that better neighborhoods attract a better class of burglers, Linux would attract sufficiently talented hackers if it were in wider use.

Linux, with its underlying foundation of old C code, is particularly vulnerable to buffer-overflow attacks.

Paul

Ever heard of Libsafe .. ?....

worth investigating i dont get problems from buffer overflow attacks thanks to Libsafe it can them before they can cause mischief ..

Pete

Silly question for you and Pete. How would you implement "Libsafe" into you Suse distro ??

Secondly other suggestions/"easy" usable pointers to make SuSE a safe place to be ;-)

TIA

Johan

You just install it and it asks if you want to deploy it system wide, say yes and it's up and running. Regards Sid. -- Sid Boyce .... Hamradio G3VBV and keen Flyer =====LINUX ONLY USED HERE=====

Why the hell did Kmail cut my name here ;-) Tirsdag den 5. oktober 2004 12:16 skrev yep@osterbo-net.dk:

Tirsdag den 5. oktober 2004 04:25 skrev Sid Boyce:

...

Johan Nielsen wrote:

...

Mandag den 4. oktober 2004 12:27 skrev Sid Boyce:

...

peter Nikolic wrote:

...

On Monday 04 Oct 2004 02:54, Paul W. Abrahams wrote:

<STUFF DELETED>

...

...

Sure, Linux is harder to break into. but after all, Linux also has its infamous rootkit. On the principle that better neighborhoods attract a better class of burglers, Linux would attract sufficiently talented hackers if it were in wider use.

Linux, with its underlying foundation of old C code, is particularly vulnerable to buffer-overflow attacks.

Paul

Ever heard of Libsafe .. ?....

worth investigating i dont get problems from buffer overflow attacks thanks to Libsafe it can them before they can cause mischief ..

Pete

Silly question for you and Pete. How would you implement "Libsafe" into you Suse distro ??

Secondly other suggestions/"easy" usable pointers to make SuSE a safe place to be ;-)

TIA

Johan

You just install it and it asks if you want to deploy it system wide, say yes and it's up and running. Regards Sid.

Thank you for that piece of info .... marked this part of the thread.

Will come in handy when I go AMD64 shopping and "retire" this P4 2.8E@3.1 (conservertively OC'ed max stable OC @ 3.4GHz) 1 gig PC as the safe point here.

Johan

On Monday 04 October 2004 13:14, Anders Johansson wrote:

On Monday, 4 October 2004 11.34, peter Nikolic wrote:

...

Ever heard of Libsafe .. ?....

worth investigating i dont get problems from buffer overflow attacks thanks to Libsafe it can them before they can cause mischief ..

Note that libsafe won't catch everything. Specifically, it won't catch buffers used in internal functions, only those used by a few select glibc functions, like strcpy and the like. And even those won't even get looked at if the program is compiled with -fomit-frame-pointer (at least the version I looked at)

Just wanted to make sure you weren't labouring under false sense of security :)

The only truly complete way to be safe from attacks is to make sure the programs don't have bugs

The work done by the OpenBSD (http://www.openbsd.org) project on all this is interesting and probably a valuable lesson too - only I'm far too ignorant to interpret said lesson for people here. Their great labours in code auditing have apparently borne much fruit in terms of getting rid of bugs, exploitable and potential, and their big code cleanups often mean that their versions of standard progs are often already fixed when new exploits appear affecting other *nixes. And they are now building with as much as possible with ProPolice / SSP (http://en.wikipedia.org/wiki/ProPolice), and Gentoo are involved as well. Interesting to see if the security gains will convince the big distros to do any of the heavy work needed to incorporate these safeguards. I expect the law of diminishing returns may mean not. Cheers Fergus -- Fergus Wilde Chetham's Library Long Millgate Manchester M3 1SB Tel: 0161 834 7961 Fax: 0161 839 5797 http://www.chethams.org.uk

Hi! I install Libsafe.I dont know how to use it ? is it correct ? poison:~ # ldd /usr/bin/grep /lib/libsafe.so.2 => /lib/libsafe.so.2 (0x40019000) linux-gate.so.1 => (0xffffe000) libc.so.6 => /lib/tls/libc.so.6 (0x40031000) libdl.so.2 => /lib/libdl.so.2 (0x40146000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Thanks a Lot!! On Tue, 5 Oct 2004 00:25:03 +0100, peter Nikolic wrote:

On Monday 04 Oct 2004 13:14, Anders Johansson wrote:

...

On Monday, 4 October 2004 11.34, peter Nikolic wrote:

...

Ever heard of Libsafe .. ?....

worth investigating i dont get problems from buffer overflow attacks thanks to Libsafe it can them before they can cause mischief ..

Note that libsafe won't catch everything. Specifically, it won't catch buffers used in internal functions, only those used by a few select glibc functions, like strcpy and the like. And even those won't even get looked at if the program is compiled with -fomit-frame-pointer (at least the version I looked at)

Just wanted to make sure you weren't labouring under false sense of security :)

The only truly complete way to be safe from attacks is to make sure the programs don't have bugs

It catches the vast majority of problems ok so not every thing is perfect but something is better than the nothing that seems to be the norm .

Pete

-- Linux user No: 256242 Machine No: 139931 G6NJR Pete also MSA registered "Quinton 11" A Linux Only area Happy bug hunting M$ clan, The time is here to FORGET that M$ Corp ever existed the world does not NEED M$ Corp the world has NO USE for M$ Corp it is time to END M$ Corp , Play time is over folks time for action approaches at an alarming pace the death knell for M$ Copr has been sounded . Termination time is around the corner ..

-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com

-- (c) gabriel.schwartz<AT>gmail<DOT>com ARGENTINA.

måndag 04 oktober 2004 03:54 skrev Paul W. Abrahams:

Linux, with its underlying foundation of old C code, is particularly vulnerable to buffer-overflow attacks.

Which is not correct ... The buffer overflow attack, is based on very old information ... let me try to explain. subroutine(const char *data) { char buffer[BUFSIZ]; ... } would, depending on architecture ... become an assembly code: allocate cost_char*_data; push return-address. push registers; allocate char_buffer[BUFSIZ]; The above is the stack... the trick here, is that the stack is filled bottom-up, while memory variables are filled top-down. So, writing over buffer[BUFSIZ+12] variables will overwrite the return-adress ( or some saved register). However, this is compiler and architecture specific. Some will save the registers, AFTER they've entered the routine. And your script kiddie, has to have detailed knowledge of the subroutine that he's going to install his rootkit in. Because, you see ... he can't have the program just return to anywhere ... that's impossible. He also has to have detailed knowledge of the processor involved, in assembly code ... as the return adress information has to include information for the memory controller, as well ... not merely the cpu, those days are long since over. All in all ... the script kiddie explanation, as I told someone earlier ... is total TB ... or Tom Bluhr. I say, it's a TB because it's not merely a deliberate lie ... it's intended to obscure the facts. In the case of closed platforms, like Windows ... you have to be in the loop of development, to know the exact size of the buffer variable. It's not always BUFSIZ long, you know ... it rarely is. In the case of Open Source, this can be a problem ... since people only have to read the source, to know. Yet, in open source, the code changes rapidly ... so you have to know what version the other side is running, as well. Which means, you have to be pretty competent to do it ... and it's usually beyond the average script kiddie. The solution, is very simple ... subroutine(const char *data) { char *buffer; buffer = malloc(BUFSIZ); ... free(buffer); } In the above case, the memory will be allocated on the heap and will consist of a memory allocation block, in 4096 byte blocks which are limited to the current process only. No program code, is within that block or near it ... that is accessable through the memory variable. The memory controller, will give a segmentation violation if the buffer is overrun into the next block, which may contain program code. I really don't think that there are many programs out there, today ... that are mission critical, that are vulnerable to buffer attacks. Of course, I haven't taken a look into the kernel ... but I doubt the kernel has any loop holes, such as the old Atari ST(e) did. You see, all you had to do with the old ST, was to put some program code in high memory somewhere and then make it warm reboot. The memory check routine would look for a signature on every 1024 block, and if found, would run a code that was there. And you really don't know what windows does or doesn't ... this is the sort of things you can do with closed architectures, but wouldn't leave lying around in an open source core. My 0,2€ worth.

måndag 04 oktober 2004 14:25 skrev Anders Johansson:

I'm not sure what you're saying here. It sounds like "it's more difficult in windows, but it's more difficult in open source"

What I'm saying is, very simple ... it's the question of "gun control". An old debate, on who is responsible. Well, in the gun control there's a saying that it's the man holding the gun, that is responsible for the damage made by the gun. Not the gun, by itself. However, some people wish to extend this to mean ... that if it isn't ME that actually pulls the trigger, than I am in the clear. Not true ... if I give a gun, to a person with significantly low intellect and then show him how to use it, and urge him to ... than I am, in fact, responsible for the damage made. To put this in the script kiddie case, the script kiddie is someone who doesn't have the knowledge of how to use it ... he gets the code, the info and the knowledge, and then he pulls the trigger. And I'm saying, you can't blame the script kiddie for his low intellect ... you can blame the employee that made the information available to him, for criminal neglegance.

It's a little more complicated than that. Google around for "heap overflow".

Actually, it's JUST as simple as that. Unless you are trying to tell me that there's a problem with how the memory controlling routines are implemented in linux. In which case, it's a serious ... yes, serious flaw in the linux kernel. And I'm well aware of some of the drawbacks on how i386 CPU's handle segments, but those drawbacks should have vanished a long long time ago, as far as I know as the segment should be handled by a true memory controller of all post pentium CPU's (again, as far as I know). The data allocated by a program, and the program code itself ... should not be within the same segment. Ok, let's say you got a program that needs 40 Megabytes of consequtive memory. But the system is heavily loaded, and there is no 40 Megabytes of consequtive memory blocks. To my knowledge, modern theory of operation says that you can have several segments and when a program writes beyond one segment, the kernel should receive an interrupt, giving it the opportunity of changing the segment of the next consequtive block. Meaning, simply, that you see the memory as consequtive, but it isn't in reality, this is also known as Virtual Memory. Thus, there should never exist the possibility that you could write beyond the segment you have allocated and certainly never into program occupied memory... unless there's a serious flaw in the handling of the heap, in which case, you need to have extensive knowledge of that case to be able to utilize it ... irrespective of who you get to pull the trigger.

måndag 04 oktober 2004 17:49 skrev Anders Johansson:

Nor do they have to be. Did you look around for some descriptions of heap overflow exploits? It really is a little more complicated than you seem to think. If it really were as simple as you put it, the world wouldn't be the security mess it is.

What you're telling me, is that in 2004 Linux still isn't using technology that was invented over 12 years ago. If that's the case, it's neglegance ... not bugs. And one can start questioning weather it's really exploits, or if its a "SPECTRE" thing (We just published our new version, it's so full of bugs that the user is forced to buy upgrades for decades to come).

måndag 04 oktober 2004 18:54 skrev Anders Johansson:

I have no idea what you're talking about, what technology would that be?

A quick google gave this:

http://www.vnsecurity.net/data/library/heaptut.txt

Thank you for a nice pointer, it just proved my point ... to use any of these exploits, you need comprehensive knowledge of the code and program to be exploited. The examples above, use an exploit on argv ... but they rely on that a certain argv pointer is used as a variable to execl. Second, in a properly implemented virtual memory manager ... data pages are not executable, and code pages are not writable. And a very well implemented memory management, will mark data pages that are loaded at runtime (program data) , as read-only (constants). Of course, that leaves variables vulnerable to being overrun, if the program doesn't care to verify that any buffered input, doesn't overflow. But, what the effect of such an action is, greatly depends on the program, the code and requires in depth knowledge of that particular scenario. The good old days, of simple "overflow the stack, to return to a data page to execute code read into the buffer", are gone. Or should be, unless someone didn't read the Computer Science textbooks right ... never really thought the stuff needed to be read over and over again, it's sorta obvious.

Anders, On Monday 04 October 2004 13:12, Anders Johansson wrote:

On Monday, 4 October 2004 21.51, Örn Hansen wrote:

...

måndag 04 oktober 2004 18:54 skrev Anders Johansson:

...

I have no idea what you're talking about, what technology would that be?

A quick google gave this:

http://www.vnsecurity.net/data/library/heaptut.txt

Thank you for a nice pointer, it just proved my point ... to use any of these exploits, you need comprehensive knowledge of the code and program to be exploited.

Yes, you're right, every exploit ever created was produced by someone with access to the source. No one could ever exploit any program ever without knowing how it was programmed

Yes and no (depending on what you mean by "how it was programmed"). One thing we don't yet have is computers (general-purpose, desktop-style computers) that can execute a program that cannot be examined, albeit in machine code form, by the person who's executing it. A diligent programmer with good tools who understands code at the assembly / machine level and understands the hardware, compiler and operating system architectural model can devise exploits without recourse to the C or C++ or assembly source code. In fact, given that stack overflow exploits (one variety, anyway) are about hijacking the execution path by overwriting the return address on the call stack, some aspects of devising such hacks are probably facilitated by examining the assembly / machine code instructions rather than the higher-level program source code. But of course, having that source code is an immense aid in devising hacks.

...

Randall Schulz

Anders, On Monday 04 October 2004 13:52, Anders Johansson wrote:

On Monday, 4 October 2004 22.45, Randall R Schulz wrote:

...

Anders,

On Monday 04 October 2004 13:12, Anders Johansson wrote:

...

Yes, you're right, every exploit ever created was produced by someone with access to the source. No one could ever exploit any program ever without knowing how it was programmed

Yes and no (depending on what you mean by "how it was programmed").

...

I was in fact being sarcastic. Should I have used a smiley?

Nope! I don't like emoticons and eschew them, myself. Looking back at what you wrote, I guess I should have grasped your meaning. Perhaps emphasis on "ever" would have helped. That's one of the reasons I'm a firm advocate of styled text in email (not to be confused with HTML mail--that's a separate matter).

...

Randall Schulz

måndag 04 oktober 2004 22:52 skrev Anders Johansson:

I was in fact being sarcastic. Should I have used a smiley?

Örn claimed earlier in the thread that all exploits ever produced were created by people with direct access to the source code, a claim which is clearly wrong. It is propagating the Redmond party line, and it has been debunked a million times over by people far more eloquent than I, but apparently Örn has missed all that.

Don't tell people, what I said ... don't start putting words in my mouth here. What you may or may not have understood, is your own personal matter and does not concern me. What I stated, is and was, that the script kiddie explanation of these exploits is, was and always will be bogus. You need far more in depth knowledge, than a script kiddie has. Which you so conveniently helped me prove, by your well thought out link ... thanks.

On Monday 04 October 2004 8:25 am, Anders Johansson wrote:

In any case, the real advantage isn't that the bugs are harder to exploit, it's that they're much easier to fix. Show me a bug in, for example, apache and give me a few hours (days?) and it will be fixed. Show me a bug in IIS and watch me sigh as I wait for a reply from MS support. It's difficult to recompile something if you don't have source code

Very true. Whether we're talking about Windows or Linux, the script kiddies depend on far better informed techies to give them the tools for their dirty work. There doesn't seem to be any disagreement here with the proposition that Linux is a far less vulnerable system than Windows. The only question is why that is. 1. The Windows code base is proprietary and closed, while the Linux code base is open source. That cuts two ways. The Linux code base has far fewer vulnerablities and those vulnerabilities that remain are more easily repaired because of the communal nature of the Linux enterprise and the many eyes that critique the code base. On the other hand, someone looking for vulnerabilities can easily examine the Linux code base but will have a hard time examining the Windows code base. Moreover, the quality of Linux code is probably far higher than that of the Windows code. It's fair to say that Linux wins this argument 80-20 or maybe even 95-5 but not 100-0. 2. It's a fact that far more attacks are aimed at Windows than at Linux, and in particular at the Outlook Express / Internet Explorer combination. That's why security folks these days recommend that Windows users switch to Mozilla (which itself is probably less vulnerable than IE, even discounting the frequency of attack). If 95% of the malefactors, script kiddies or otherwise, devote their energies to Windows rather than to Linux, it stands to reason that all other things being equal (which of course they're not), Windows users will be hit far more often and far harder. Paul Abrahams