Slashdot Mirror

I would suggest having a look through some of the recent Bugtraq archives. These can be found at SecurityFocus. Have a look at some of the problems found in IE lately. This is & has been a problem for a long time. Here's a Hotmail example. There are postings regarding similar problems with most of the web based email services. Active scripting causes more problems than javascript.

It has been recommended that you disable all scripting for security reasons for a while now. It's very good practice.

Note that not every Microsoft security vulnerability out there is listed, either. Do a search on vunlerabilities by vendor for Microsoft at Security Focus, which is at http://www.securityfocus.com to see all 235 vulnerabilities listed, most of which Slashdot missed.

Good resources for Linux security news, specifically, are Linux Weekly News at http://lwn.net/ and its continually updated Daily Edition at http://lwn.net/daily/ For additional resources you can visit Linux.Com's security section at http://www.linux.com/security

Sorry bout the spam of the previous post, but that's the listing of the /pub/LinuxOne/Source directory on their FTP site. I'm not familiar with my RPM nomenclature, but aren't *mdk.src.rpm RPM sourcefiles from Linux-Mandrake? On another note, I noticed that they were using BeroFTPD 1.3.4 I wonder if they keep up to date with their security patches? (insert witty quote here)

First off.. Do not just "Scrub" the system. Wipe the HD, LLFing if possible. Backup data files first, via the network to a known good server first (via anon FTP so any remaining sniffers, etc, will not read any important password).

Then go and reinstall a recent Linux distro. I recommend Slackware. It may not have the bells & whistles of Red Hat, but its BSD-style init scripts are easy (easy as config.sys and autoexec.bat) to learn, and tends to ship with reasonably secure daemons. Of course, OpenBSD is another possible solution :-)

Now, if you want to just give them FTP access (and nothing else), ProFTPD provides a nice solution. Granted, earlier versions had some interesting security holes (poke), recent versions have been a lot better security wise. Set it up with mod_linuxprivs (which uses the POSIX.1e interface of 2.2.x and later kernels to drop all root privs except for the ability to bind to ports less than 1024). (For the configure impaired, try "./configure --prefix=/usr --with-modules=mod_linuxprivs").. This lets them have ftp access (I'd also recommend you setup ProFTPD to chroot the various users to their homedirs). Disable telnet. Install SSH or OpenSSH and only allow your own login to use it (login.access allows this). Only allow your user to execpt su (perhaps as part of the wheel group), and have your root password as something other than your normal account password. At this point, you will have a secure system, FTP access for normal users, and secure remote access for your own administration. Of course, this doesn't get you out of your duties to monitor Bugtraq for possible advisories. I also recommend (very much so) that you read LASG -- the Linux Administrator's Security Guide. It's very good :-)
---

it's hard to use this list to compare linux vs. NT, because lots of the bugs listed for the operating systems are in add-ons and third-party products.

the nearest statistical comparison of openrating-system-security is on attritions web-defacement-counter. in the overall OS-count from august 1999 to present Win-NT is leading clearly with 55%, followed by linux with 19% and solaris with 13%. source: http://www.attrition.org/mirror/att rition/os.html

these total number of defacements should also take into account, that there are more webservers running on linux than on NT, as can be seen here.

open source brings a security-problem which is not as big in closed source: it's far easier to write trojans. but this risk is small compared to backdoors intentionally implemented by clodes-source software manufactures. a good example is the international version of lotus notes where the NSA knows 24bit of the 64bit-key.

it's hard to use this list to compare linux vs. NT, because lots of the bugs listed for the operating systems are in add-ons and third-party products.

the nearest statistical comparison of openrating-system-security is on attritions web-defacement-counter. in the overall OS-count from august 1999 to present Win-NT is leading clearly with 55%, followed by linux with 19% and solaris with 13%. source: http://www.attrition.org/mirror/att rition/os.html

these total number of defacements should also take into account, that there are more webservers running on linux than on NT, as can be seen here.

open source brings a security-problem which is not as big in closed source: it's far easier to write trojans. but this risk is small compared to backdoors intentionally implemented by clodes-source software manufactures. a good example is the international version of lotus notes where the NSA knows 24bit of the 64bit-key.

1. Check if it has already been found. Security Focus & the Bugtraq archives are a good place to start.

2. If it is a new vulnerability notify the vendor responsible.

3. Wait an appropriate amount of time (opinions vary on this part). If the vendor fails to respond post the info & the exploit if you have one to Bugtraq or similar list.

4. If the vendor does release a patch/notice release your details as well.

At no point should leaking it to the press to make a fuss be an issue. Full disclosure is a good thing, but in the appropriate forums. Some vendors are very cooperative & release patches (or at least a notification) very rapidly. Others never get around to addressing security holes.

This only proves a point that I've long been trying to make to those who have been of the opinion that "once Microsoft enters the server market, the Bad Old Days of needing arrogant computer gurus will be over." Frequently heard in pre-WinNT days and apparently still believed by many.

The point is this: sophisticated and powerful computing problems need sophisticated solutions, implemented by knowledgeable and talented computer engineering professionals.

Make no mistake: this kind of thing is not Microsoft's fault. It was just an amusing irony that MS server products were the ones that were discovered/investigated. And lest anybody think that non-MS platforms/software are unlikely to suffer the same kind of fate: witness the Serious Bug in MySQL password handling recently reported on bugtraq. How many E-Commerce site admins running MySQL do you suppose don't even know about that one, much-less have it plugged?

Where Microsoft is to blame, IMO, is in promulgating the myth that their products take the complexity out of complex problems. Sorry, but it just ain't so. What they do accomplish is burying details so effectively that the solutions appear simple. (And, ironically, even if you know they're not: making it hard to "get to the root of things." [No pun intended.])

Real computing problems require real solutions implemented by real computer-savvy, intelligent and, perhaps most of all, focused and responsible engineers. Not some liberal arts or business marketing graduate that took one-or-another vendor course and got his or her "certificate." Regardless of the chosen solution. (Tho I, personally, do not recommend MS-based solutions.)

You got that right!

I wonder how many of these web-hosting sites that provide MySQL, for example, are even aware of the recently-discovered, very dangerous and easily exploited security hole found in MySQL? (Ref: Serious Bug in MySQL password handling)

This isn't a criticism of MySQL (use if myself), but by way of illustrating a very real concern.

One question I'd ask any prospective Web hosting company is what security-related resources their staff subscribes to. (I wouldn't ask them specific questions about specific resources--but let them provide me with a list.)

Here's what scares me about these operations: they can't even handle something as simple as UUCP (noted in another comment), but they expect me to trust them with allegedly secure Web-hosting solutions? (Which is much, much more difficult.)

At the end of 98 a group did a bulk scan of most of the internet for 18 common remotely exploitable security vulnerabilities. Here is a summary:

BEGIN TIME: 02:00, Dec 01, 1998 GMT
END TIME: 08:00, Dec 21 1998 GMT

Scanning nodes: 5
Jobs Per Minute: 250
Scan time: 20.24 days

Vulnerabilities tested: 18

Domain count: 7 three letter domains, 214 national domains (see suffix item 3)
Host count: 36,431,374
Vulnerability count: 730,213
Vulnerable host count: 450,000

I leave it as an exercise for the reader to work out what people should be doing before setting up a "global, round-the-clock anti-cybercrime network". I fear that it might take a few more CDuniverses to shock business into taking security seriously.

Details are here: The Internet Auditing Project - It's actually quite an interesting read. Also features details on how one of thier highly secure linux boxes was cracked with an amazing super-crack. This is a good example of how one cracked host and bring down other secure machines.

--
Simon

Hmmm... patches like this are somewhat useless unless:
A: The patch protects the Mac from getting attacked by a DOS.
B: People are stupid enough to dl them.

Don't you mean smart enough to download them? If you're not smart enough to get patches for your favourite OS, then you have a problem.

most people want their computer to be safe from DOS

Ergo this discussion of MacOS :-) DOS is such an evil bastarization of CP/M and Unix(r).

At least this security problem was redressed quickly. There was no "force closing of apps" patch for the logout problem mentioned on BugTraq, nor one for the MacOS 9 weak password encryption.
---

Hmmm... patches like this are somewhat useless unless:
A: The patch protects the Mac from getting attacked by a DOS.
B: People are stupid enough to dl them.

Don't you mean smart enough to download them? If you're not smart enough to get patches for your favourite OS, then you have a problem.

most people want their computer to be safe from DOS

Ergo this discussion of MacOS :-) DOS is such an evil bastarization of CP/M and Unix(r).

At least this security problem was redressed quickly. There was no "force closing of apps" patch for the logout problem mentioned on BugTraq, nor one for the MacOS 9 weak password encryption.
---

Hmmm... patches like this are somewhat useless unless:
A: The patch protects the Mac from getting attacked by a DOS.
B: People are stupid enough to dl them.

Don't you mean smart enough to download them? If you're not smart enough to get patches for your favourite OS, then you have a problem.

most people want their computer to be safe from DOS

Ergo this discussion of MacOS :-) DOS is such an evil bastarization of CP/M and Unix(r).

At least this security problem was redressed quickly. There was no "force closing of apps" patch for the logout problem mentioned on BugTraq, nor one for the MacOS 9 weak password encryption.
---

As you are one of the most well-known security-focused-groups today, you must surely attract a lot of young people who would want nothing more than to follow in your footsteps. Every kid nowaday wants their umpteen minutes of fame and TV air time.

What are your thoughts on the reponsibilities you have as frontal figures for the "hacking community"? (For some non-disclosed definition of "hacker")
Do you feel such a responsibility to steer the young and naive hacker-wannabies into white-hat territory? - or are you more into "give them the knowledge, let them choose side for themselves"?

If you feel an obligation to inspire kids towards non-illegal, non-confrontational, non-disruptive hacking; how do you take on such a task? Your choice of a name that surely goes well within script-kiddie-hacker territory indicates to me either a wish to attract such a following, or perhaps it is just an indication of your history, coming from that background.


Enough rambling, I guess my question more or less boils down to "How do you install a sense of decency in your fan groups?"

By the way, thank you for all your good security work. It seems you appear in my bugtraq and ntbugtraq e-mail folder every other time I look... I hope I don't come across as insulting or demeaning in my question, I am seriously interested in your answer.

For more details on OpenSSh and OpenBsd check out this BugTraq posting on the issue.

It's interesting that the CERT advisory was dated yesterday.. I saw a notice a couple weeks ago here, unless this is another RSAREF2 issue. If it is the same, I'm curious what the delay was for, does CERT do its own research/checking on matters before releasing advisories, or did it simply take awhile for word to spread?

/Joakim Crafack

As I understand it, there are two issues here, and a lot of knee-jerking going on as well. First off, the protocol issue. I think Microsoft / AT&T have every right to try and clone the protocol used by AIM. I think there may even have been legal rulings over in the US about the legality of reverse-engineering protocols. AOL, of course, are entitled to change there protocol, but leaving a gaping security hole (allegedly) in the clients to do so is unacceptable. Secondly, there's the question of access to servers. AIUI, Microsoft's client was connecting to AOL's servers in order to communicate with AIM users. Regardless of what you feel AOL ought to do, those servers are their property. They have the right to decide who should and should not have access. If they decide the servers are for use only by AOL/AIM users, it's their choice. If I understand correctly, Microsoft or its software's users might have been committing an offence under the UK's Computer Misuse Act.

These systems will be running the server software they need, and X11 + (Gnome||KDE) for administration and so on.

• video hardware (& its drivers) tends to be one of the touchiest areas of a system, best avoided if you're not using it as a workstation,
• You're wasting resources that could be used for serving on your X environment (especially with some of those new-fangled screensavers ;)
• It's better to understand configuring the system the *right* way - via the command-line tools and configuration files. That way, you can keep multiple versions in case something goes wrong and you need to back out a change.

Is OpenBSD more secure in some fundamental way that a well maintained Linux distribution?

Is OpenBSD more stable than a well maintained Linux distribution?

Will the OpenSource software we normally need (firewall, Apache, PHP4, Perl, Python) and so on probably compile on OpenBSD?

Does OpenBSD support multiple CPU's better then Linux?

One thing that BSD is currently very helpful with on the x86 architecture is large file support. The Linux limit is 2gb, so your MySQL databases are limited to that size.

Yeah there's a buffer overflow in the software. This is pretty wierd/bad since it's one the only pieces of software that has a security hole put in it on purpose and with a lot of forethought. check out this for more details.

The AOL IM actually has a buffer overflow exploit present. Basically whenever an AOL client connected to the server, the server smashed the stack and executed a piece of code that would send a packet back to the server. This let AOL change the authentication on the fly without updating the client. Of course, it also opened up some security holes. This was discussed on bugtraq in August.

One aspect of OpenSSH that many people should like is that the most recent security hole in ssh-1.2.27 was non-existant in OpenSSH. For that reason alone, OpenSSH might be a better choice -- especially with the lack of developer news concerning ssh1 and ssh2.

-B

ps. Check www.securityfocus.com for the bugtraq archives and mailing list.

Date: Tue, 16 Nov 1999 09:36:44 +0000
From: "Alan J. Wylie"
Subject: Re: Windows NT update carries bug
To: BUGTRAQ@SECURITYFOCUS.COM

>>>>> "Ken" == Williams, Ken writes:

[snip]
Ken> A software update for Microsoft's Windows NT operating system
Ken> introduced a bug that could potentially cripple Lotus Notes
Ken> unless companies compromise network security.

Ken> The bug in Windows NT Service Pack 6 prevents users from
Ken> accessing Lotus Notes without administrator rights--the
Ken> highest and broadest level of access typically reserved for
Ken> network managers.
[snip]

SP6 also stops VNC[1] from working unless run with administrator
privileges. The error message is something like "error
disabling Nagle's algorithm". This is apparently a result of
a _tightening_ of security in the TCP/IP code.

For more discussion, see:
http://www.uk.research.att.com/vnc/archives/1999 -11/0087.html

[1] an open source cross platform remote display system,
http://www.uk.research.att.com/vnc/

--
Alan J. Wylie (Cyrano UK Ltd.) | mailto:alanw@cyrano.com
http://www.cyrano.com | http://www.glaramara.freeserve.co.uk/

Date: Tue, 16 Nov 1999 11:32:46 -0500
From: Peter Kane
Subject: Re: Windows NT update carries bug
To: BUGTRAQ@SECURITYFOCUS.COM

This is not just a problem with Lotus notes. I found this problem also
exists with Wall Data's "Rumba"

---
Peter M. Kane, MIS Specialist

You cannot get a virus simply by reading email

That used to be true. Now, thanks to HTML-enabled java-enabled mailreaders and trusted ActiveX documents, you can. (Those aren't just buzzwords)

I'm safe with pine, though.

Oh, wait, pine had a problem handling MIME headers at one point not TOO long ago... See the message on security focus.

MS Outlook had problems with a buffer overflow in MIME headers.

Everybody back to mailx!

link to original bugtraq messages archieved at www.securityfocus.com

You're not serious are you? This is nonsense and naive at best. You're not familiar with BUGTRAQ are you? BUGTRAQ is a mailing list that is a critical resource for admins all over the world. BUGTRAQ is also a full disclosure mailing list and it is open to anyone to read. Attempting to hide this information will only serve to keep it out of the hands of the people who need it. Clever crackers will find it regardless. Furthermore, open disclosure encourages the fixing of security holes. Hiding this information will lull people into a false sense of security.

Perhaps you should spend some time reading at Security Focus and Packet Storm to understand why full disclosure is a _good_ thing. You are fooling yourself if you thing licensing and attempting to hide security holes will provide any protection whatsoever.

These "hack this box" attempts are nothing more than publicity stunts, meant to satisfy a particular political agenda. They prove nothing technically.

These stunts generally only attract script-kiddies... a population against which any reasonably competent sysadmin can protect themselves against with a fair amount of effectiveness no matter WHAT their OS is (yes, even NT).

The type of cracker that doesn't go in for these cheap publicity shots is the type that you really need to be worried about anyway, and those crackers will penetrate your defenses no matter what you do to stop them.

For an interesting read on the type I'm referring to, check out the 8 second crack article on the internet auditing project. It's a long (but interesting read), the particularly juicy part is down in the Third week section.

That kind of cracker doesn't particularly care which OS you're running, they'll drop you in your tracks no matter what.

-- Gary F.

Actually Joel, NT has been cracked in the real-world environment on more than one occation. In fact, in a story posted on /. about security and the internet (this is the one about the security company scanning a large portion of the to find out just how insecure the internet really is) they noted that thier own network (a security firm nonetheless) had been cracked into because of two NT machines (an employees machine at home and one of their servers at work). Further, they noted that the NT log files were of no help figuring out how the person got in to the first NT box--they still don't know how it happened!

To see what I'm talking about go here htt p://www.securityfocus.com/templates/forum_message. html?forum=2&head=32&id=32 and scroll down to the section with the header of "Third week" and read it for yourself.

I agree entirely with the other guy who responded (I wish I had a short-term memory). Phrack is not some script-kiddie-house-o'-sploits. You'd have better luck looking at securityfocus.com (one of your "responsible" groups) for those. I haven't read all of it, but the articles I did read were much more into proof-of-concept and discussing technical issues than providing .c files to compile and run against your favorite hosts (note to script kiddies: nsa.gov is probably *not* the best place to test your k3wl sploit. Now back to our regular programming.) Bugtraq probably has more 'sploits, and you cite that as a "responsible" group. The only difference is that a lot of phrack contributers find holes because it's fun and challenging, not because they're getting paid to admin hosts that use swiss-cheese-security. (Not to imply that because one is getting paid to be a security consultant one can't still be a hacker, just that I get the impression that a much greater percentage of the people posting to Phrack are hackers in the pure sense just because that's what they are (in the "Gee, I wonder how this thing works" sense, not in the "d00d, let's generate some credit card numbers!", which isn't hacking at all, unless you actually reverse engineered the system to generate numbers and whatnot. Bonus points if you build a magstripe maker from household components, but anyhow). I just wish my C and assembly skills were up to the level necessary to do some of that stuff...

This is an excerpt from a summa ry of the internet auditing project.
Friday, our Japanese participants discover that a computer on their company network has been cracked into, one very secure Linux box running only SSH and Apache 1.3.4. Now this would definitely send a chill up your spine if you knew just how fanatic our friends are when it comes to network security. Furthermore, they only detected the intrusion three days after the fact, which is unbelievable when you consider the insane monitoring levels they've been keeping since they agreed to participate in the scan. They would have noticed any funny stuff, and in fact, they did, lots of it, but none of which came close enough to a security breach to raise any alarms.
[..]
The attacker knows the employee's username and password and is even connecting through the employee's Japanese ISP on the employee's account! (the phone company identified this was an untraceable overseas caller)

This information could not have been sniffed, since network services are only provided over encrypted SSH sessions.

Further investigation shows that this employee's personal NT box, connected over a dynamic dailup connection, had been cracked into 4 days earlier.
[..]
How the NT box was cracked into in the first place is still a mystery. The logs weren't helpful (surprise! surprise!) and the only way we were even able to confirm this had happened was by putting a sniff on the NT's traffic (following a hunch) and catching those sneaky packets redhanded, transmitting our SSH identification down under.

Hmmm...

For a bug that cmdrtaco considers dangerous, this isn't the type of fast patching I'd expect. I always hear bragging that Linux fixes bugs in a few days of their discovery.

According to the bugtraq post about the bug, the discoverer contacted kernel developers in May. That was three months ago. After receiving little response, he posted to Bugtraq on July 31. Now, nearly a month later, the bug finally gets fixed.

Three month turn-around times for important bugfixes doesn't seem like anything to brag about.

Read BugTraq's technical discussion.

Add BugTraq to your bookmarks:
http://www.sec urityfocus.com/templates/archive.pike?list=1&threa ded=1

Read BugTraq's technical discussion.

Add BugTraq to your bookmarks:
http://www.sec urityfocus.com/templates/archive.pike?list=1&threa ded=1

Some very interesting discussion about AntiSniff took place on the bugtraq mailing list; here are the relevant threads (and yes, there is already an AntiAntiSniff Sniffer :) :

• 07/23/1999 - The Original AntiSniff Announcement
  
• 
  07/25/1999 - People start trying to figure out workarounds
  
• 
  07/25/1999 - Another discussion thread on AntiSniff and how it works.
  
• 
  07/25/1999 - The AntiAntiSniffer Sniffer is released: "All Hail The AntiAntiSniffer Sniffer!"
  

Some very interesting discussion about AntiSniff took place on the bugtraq mailing list; here are the relevant threads (and yes, there is already an AntiAntiSniff Sniffer :) :

• 07/23/1999 - The Original AntiSniff Announcement
  
• 
  07/25/1999 - People start trying to figure out workarounds
  
• 
  07/25/1999 - Another discussion thread on AntiSniff and how it works.
  
• 
  07/25/1999 - The AntiAntiSniffer Sniffer is released: "All Hail The AntiAntiSniffer Sniffer!"
  

Some very interesting discussion about AntiSniff took place on the bugtraq mailing list; here are the relevant threads (and yes, there is already an AntiAntiSniff Sniffer :) :

• 07/23/1999 - The Original AntiSniff Announcement
  
• 
  07/25/1999 - People start trying to figure out workarounds
  
• 
  07/25/1999 - Another discussion thread on AntiSniff and how it works.
  
• 
  07/25/1999 - The AntiAntiSniffer Sniffer is released: "All Hail The AntiAntiSniffer Sniffer!"
  

Some very interesting discussion about AntiSniff took place on the bugtraq mailing list; here are the relevant threads (and yes, there is already an AntiAntiSniff Sniffer :) :

• 07/23/1999 - The Original AntiSniff Announcement
  
• 
  07/25/1999 - People start trying to figure out workarounds
  
• 
  07/25/1999 - Another discussion thread on AntiSniff and how it works.
  
• 
  07/25/1999 - The AntiAntiSniffer Sniffer is released: "All Hail The AntiAntiSniffer Sniffer!"
  

Threats to company assets can be of internal or external origin. For many companies that have a computer security policy, client-side executable content presents unacceptable levels of risk in both intranet and Internet environments. The serious security risks of using Javascript and other executable content in web browsers are explained elsewhere -- one of the best information sources is BugTraq's Ja vascript security problems.

Actually, the risk is in enabling Javascript or ActiveX on any web browser. Some people may swallow the pleasing arguments of the manufacturers' marketing agents in favour of these two proprietary technologies. However, real companies with assets to protect need to have a strict security policy to control the content of communications to and from networks including both intranets and the Internet. The type of content most likely to bring serious hazards is executable content such as Javascript. Many companies therefore have a security policy that forbids the use of Javascript et al in web browsers. Javascript et al have a history of serious security problems -- one of the best information sources on this topic is BugTraq's Ja vascript security problems.

Furthermore, many companies avoid using Javascript and ActiveX on their web sites because they do not want to lock out potential customers from companies that do not allow Javascript or ActiveX.

Remember, executable content is a security problem looking for a victim.

Signed, eb3916bc02f11be10143de045c5a0cc5

i haven't seen any company pull down their website because it was cracked.

You misunderstand; the security problems exist mainly at the client side when you let someone else's web site feed your computer with hazardous Javascript. That's the real security risk. Internet access by itself is neither good nor bad. The solution is to have a company security policy to control the content of the communications to and from the Internet. That's why many businesses already have a security policy that forbids the use of scripting languages like Javascript and ActiveX by web browsers. Of course, if you don't have any assets to protect, you probably don't care about such security problems!

An excellent place to learn about new security problems in general is BugTraq at www.securityfocus.com Read what BugTraq has to say about Ja vascript security problems.

i haven't seen any company pull down their website because it was cracked.

You misunderstand; the security problems exist mainly at the client side when you let someone else's web site feed your computer with hazardous Javascript. That's the real security risk. Internet access by itself is neither good nor bad. The solution is to have a company security policy to control the content of the communications to and from the Internet. That's why many businesses already have a security policy that forbids the use of scripting languages like Javascript and ActiveX by web browsers. Of course, if you don't have any assets to protect, you probably don't care about such security problems!

An excellent place to learn about new security problems in general is BugTraq at www.securityfocus.com Read what BugTraq has to say about Ja vascript security problems.

Some anonymous coward wrote:

IRC does not scale

Doesn't scale? Actually, in some ways I'd say IRC scales better...if the traffic gets excessive, people start new servers on the network which are closer. (I'd say it scales approximately as well as large FTP sites like Simtel or Freshmeat; Freshmeat in particular is actually mirrored on a large number of sites and one is routed to a server semi-local to one.)

IRC does not have a user registration system

Depends on the network, actually. The largest IRC network admittedly has no facilities for nick registration (then again, the largest IRC network is next to useless for many reasons). Second- and third-generation IRC networks, such as DALnet and SorceryNet have NickServ programs that allow registration of nicks...if someone else tries to logon with your nick, they have to give your password within 30 seconds or their nick gets autochanged. (You can also specify hosts that don't have to give a password.)

IRC does not have offline messaging

Again, this varies with IRC network and server. IRC servers on DALnet, SorceryNet, and other networks that use the DALnet server software do have offline messaging capability as long as your nick has been registered. The tool is called MsgServ, and when someone logs on they'll get a message to the effect "x messages are waiting for you. Type /msg MsgServ read 1 to start reading".

IRC servers periodically split off because of the massive amount of traffic since IRC as a protocol forwards every single message, not just the ones the people on the other server are interested in seeing

I've got some news for you...so does AIM. So does ICQ. The servers by definition carry every message on them, not just the ones one is interested in seeing! You just see the ones you're interested in seeing because you're in a chatroom (the exact equivalent of a room on IRC) or you are in private chat with a person on your Buddy list (the exact equivalent of either private chat (/msg) or DCC chat in IRC).

The real reason IRC tends to lag is because of network conditions in GENERAL on modern IRC networks (like Undernet and DALnet and SorceryNet). They often have to cross country and worse...AOL actually uses multiple servers for AIM (and I expect for ICQ as well) but they're located in two or three places. I'll also note that IRC networks with two or three servers almost never experience lag problems; I've not yet run into serious lag on SorceryNet, for instance.

As a minor aside...I have run into problems with network lag with ICQ (at times I honestly wish you could select the server you connect to; sometimes ICQ is so slow as to be unusable) and I know folks who've run into it with AIM too. The problem isn't exclusive to IRC. Just three problems, I can easily give you a hundred more if you like.

Most of the problems I've seen with IRC versus "chat clients" such as AIM or ICQ mostly occur on EFnet (a first-generation IRC network which is mostly plagued by script kiddies). Modern servers such as DALnet and SorceryNet (and networks and private IRC servers using the DALnet ircii server) generally do not have the problems with script-kiddies and people on kick-frenzies, and have security for nicks and channels as well as less problems with netsplits. (And yes, I've seen the equivalent of netsplits on other chat clients; with ICQ "netsplits" you generally are unable to talk to the person even though they are still online.)

In fact, I'll even go so far as to note that there are problems with AIM and ICQ that do not exist on third-generation IRC systems. Firstly, it is well known that the name registration in both AIM and ICQ are insecure and it is possible to spoof nicks (BUGTRAQ has good info on vulnerabilities in the clients). Secondly, it is more difficult to secure non-private chatrooms in AIM (ICQ's chats are, essentially, the equivalent of invite-only IRC rooms; third- and even second-gen IRC servers allow one to set a room's mode automatically to only allow certain people in, or only allow certain people to post, and keep those configurations fairly permanently set even when one is not on IRC). Thirdly, you're relying on protocols which are largely proprietary and (as is being shown by the entire AIM debacle) permission for clones to operate can be revoked at a moment's notice leaving you to either buy a client from a proprietary vendor (if you use Windoze or maybe MacOS) or leaving you essentially SOL (if you use Linux or any other OS, or if you don't like giving AOL your dime so they can keep sending coasters, er, "try out AOL free for thirty days" CDs). It is rather difficult to start one's own ICQ server, and probably impossible to start one's own AIM server, if you don't like AOL's policies.

Other chat clients are even worse. Ichat, a common "web chat" util, pretty much has equivalent function to IRC but with none of the security features of even first-generation IRC servers...I personally have seen script-kiddies spoof nicks, do kicks of entire channels, effectively take over entire servers, commit DoS attacks on users...and there is no way to set operator status on a channel (it's only server-wide, the equivalent of an IRCOp) and no way to protect users or channels from this sort of sillybuggers (not even bots to guard a channel).

With IRC, on the other hand...third-gen clients allow all of the features of ICQ or AIM, with more security. IRC is an open protocol; clients are available for damn near every system under the sun (including DOS boxen as low as 8086's and old Amigas), most IRC servers are open-source (the complete source for the DALnet server, the base for most third-gen IRC servers, is available from their website; it's basically a version of the regular EPIC ircii server with extra features), and if you don't like the policies a server or network is doing you can get with friends and start your own server (this is exactly how SorceryNet started, btw; they thought DALnet's admins were being right bastards, so they took their toys and started their own network).

The only problem is there are several IRC networks. I do know that at least some folks are working on various ways of letting them talk to each other, though...this includes gateways (I knew a person working on an experimental DALnet/ SorceryNet gateway, for instance) and clients that allow people even on different services to talk to each other (in essence the clients act as IRC/AIM/ICQ/whatever gateways).

You need to learn the security risks of Javascript. An excellent place to learn about new security problems in general is BugTraq at www.securityfocus.com. Read what BugTraq has to say about Ja vascript security problems. It should be no surprise that technically aware companies usually have a computer security policy which bans the use of Javascript and ActiveX.

You need to learn the security risks of Javascript. An excellent place to learn about new security problems in general is BugTraq at www.securityfocus.com. Read what BugTraq has to say about Ja vascript security problems. It should be no surprise that technically aware companies usually have a computer security policy which bans the use of Javascript and ActiveX.

see the Linux Weekly News' Security page for information on Linux security projects which are already under way:
Secure Linux Projects Bastille Linux
Khaos Linux Secure Linux
Security List Archives
Bugtraq Archive
Firewall Wizards Archive
ISN Archive

Distribution-specific links
Caldera Advisories
Debian Alerts
Red Hat Errata
SuSE Announcements

Miscellaneous Resources
CERT
CIAC
Comp Sec News Daily
Crypto-GRAM
Linux Security Audit Project
OpenSEC
Security Focus
SecurityPortal

..unpatched security holes in Windows 95, 98, and NT that allow unpriviledged users..

Unpriviledged users? In Win9x? Sure...

Also, I might be wrong here but BO2k does not spread itself (but it could though).

By your logic, Microsoft should come out with security patches for Laplink and Pc Anywhere! Of course there just as many "un-informed" people who leave those set for public access as people who add accounts on their unix boxes without passwords.

Here's a great security advisory: starting IIS and changing the webroot to C:\ can allow remote users to get your files. I guess microsoft should issue a patch to block the webroot from being changed to c:\!

Now for a real exploit.. Send messages to every linux user you know but encode the message with the remote pine exploit. Have it download a small script that will put ~/bin as the first directory in their PATH and download a trojan 'su' program to their bin/ directory. The next time they su, it will mail you the password. Now THAT is an exploit! This could be done entirely in perl for cross-platform exploitability.

See the obvious difference here? For BO to run, it requires a specific user action. This pine exploit (there is just about one for every version) runs WITHOUT user action. Just reading a message which results in downloading code and executing it is a bad thing(tm).

Note: The pine 4.10-1 rpm with redhat is patched with this patch which prevents actual execution but other distributions may not be so lucky.

I agree 100% with your comments about JP but everything you said also applies to Ken Williams. He decided to use his security site as a platform to publish crap about soneone else and then tried to blame JP for his site being removed. Next, he and his coherts at crackernews.com go on to claim Harvard destroyed all of the security related files (which can be found in the BugTraq archives) but they manage to "recover" the infamous /jp/ directory and place it online. I certianly see where Ken's priorities are now! He, like JP and many others in the "hacker" community has chosen to spend more of his time trying to destroy specific people rather than help the community as a whole. The strangest part of this whole situation is that even after Ken's little game has been exposed, people still try to defend him.

Right now, securityfocus.com seems to be the best bet.

if you want to hear the truth about antionline, go to attrition or you can kill JP online at anti0nline (click on kill jp) .. personally I hope that real security sites like securityfocus.com kill antionline for good

thats my 2 cents

-robohaqr

if you want to hear the truth about antionline, go to attrition or you can kill JP online at anti0nline (click on kill jp) .. personally I hope that real security sites like securityfocus.com kill antionline for good
thats my 2 cents
-robohaqr