Re: Apache/Expat/Sablotron
Paul Iadonisi [EMAIL PROTECTED] writes: I forgot to mention that I did do a Google search on 'sablotron expat apache segfault' and found lots of references to this exact type of problem. The results seem to universally point to multiple copies of the expat processor due to the fact that many products (apache included) include their own copy of expat. You need to verify that you have *one* *consistant* version of expat on your system. Depending on the version, whether it's linked statically or dynamically and anything else you are using that needs expat, there can be serious conflicts. It has something to do with instantiating the parser multiple times and then the code that makes the call to the parser doesn't know which instance to call. Something like that. Har! I wonder if they use yacc for their parser... Anyhow, based on what I read, it appears that I've got everything set right. Red Hat's apache 1.3.22 update links dynamically to the external expat. So does the 0.71 rpm of sablotron from the Ginger Alliance. Even the perl-XML-Parser is linked dynamically, though we don't use that. The only thing I can think of that might not be is php (which we use a small bit of), but we don't even use any of the XML stuff in php and I don't think we've even reached the point where php would be loaded. I may be wrong, though, as I know little about the inner workings of apache. Do you happen to end up with a file named core anywhere as a result of this problem? Are there any references to LD_LIBRARY_PATH anywhere in this mix? --kevin -- Kevin D. Clark (CetaceanNetworks.com!kclark) | Cetacean Networks, Inc. | Give me a decent UNIX Portsmouth, N.H. (USA)| and I can move the world alumni.unh.edu!kdc (PGP Key Available)| * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: Apache/Expat/Sablotron
Since it sounds like you are able to build the failing module from source, you might be able to have it cooperate with you in your attempts to attach to it with GDB. For example, you could add some code at the beginning that would create a file with a recognizable name in /tmp. Your code would write your PID into that file and then stand around waiting until that file no longer exists before resuming normal operations. Then when you run the failing app, you'd wait until that file were created in /tmp, start up an instance of GDB, tell it to attach to that PID and then delete the file, signalling the app to proceeed. When the fault occurred GDB would halt the app and allow you to look around. If you're lucky you'll discover that you've made the faulting reference in your own code and can fix it immediately. On the other hand you might discover that you've tripped over a bug in some library code, which would suck. GPL all the way: Sell services, don't lease secrets Cool! Where do I send the bill? Regards, Michael O'Donnell [EMAIL PROTECTED] ### # This transmission has not been approved # # by the Office of Homeland Security. # ### * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
HPUX break in
A fellow I work with inherited an HPUX machine and of course, nobody knows the root password. Does anyone know of a 'break in' procedure he can try? -Andy * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: Apache/Expat/Sablotron
On Wed, 2 Jan 2002, Paul Iadonisi wrote: Here's what doesn't work: OS: Red Hat 7.2 Apache: 1.3.22 (official update from RH) (built dynamically against supplied expat rpm) Cold Fusion: 5.0 Sablotron: 0.71 Expat: 1.95.1 (supplied with Red Hat 7.2) Have you tried rebuilding everything from source? As has been noted many times, binary compatibility is hard. Subtle differences in the build environments often manifest themselves as segfaults in the run environment. Now, Cold Fusion is a commercial product, so you'll have to work around that, but the rest is Open Source. Remove all the Red Hat supplied RPMs for everything that even smells like it might be related to Apache. Then obtain the latest stable releases of everything as source tarballs, RTFM, and do what the FMs say. Check the CF docs for details about how it will integrate with source builds. Good luck! -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: HPUX break in
Andrew W. Gaunt [EMAIL PROTECTED] writes: A fellow I work with inherited an HPUX machine and of course, nobody knows the root password. Does anyone know of a 'break in' procedure he can try? If you *absolutely* don't have the root password: (from my very old (possibly incorrect) notes...) 1: shut off the system (no way to gracefully do this w/o the root password) 2: IIRC, while the system is starting up, if you hit ESC twice, you'll interrupt the booting process. 3: At the boot_admin prompt type: boot pri isl 4: At the isl prompt type: hpux -is If the previous admin configured the system in trusted mode, this will *not* work, and you'll have to boot from the original media. Regards, --kevin -- Kevin D. Clark (CetaceanNetworks.com!kclark) | Cetacean Networks, Inc. | Give me a decent UNIX Portsmouth, N.H. (USA)| and I can move the world alumni.unh.edu!kdc (PGP Key Available)| * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: HPUX break in
Andrew W. Gaunt [EMAIL PROTECTED] writes: A fellow I work with inherited an HPUX machine and of course, nobody knows the root password. Does anyone know of a 'break in' procedure he can try? Is this machine involved in a NIS domain? Can the NIS administrator login/su? --kevin -- Kevin D. Clark (CetaceanNetworks.com!kclark) | Cetacean Networks, Inc. | Give me a decent UNIX Portsmouth, N.H. (USA)| and I can move the world alumni.unh.edu!kdc (PGP Key Available)| * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: HPUX break in
I know this would be a MAJOR pain, but but crackers have been rooting machines for years. Could the CERT archives provide a way ? On Thursday 03 January 2002 07:53, Andrew W. Gaunt wrote: A fellow I work with inherited an HPUX machine and of course, nobody knows the root password. Does anyone know of a 'break in' procedure he can try? -Andy * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. * * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: HPUX break in
Everyone, Thanks for the suggestions, he has sucessfully broken into the machine. -Andy On Thursday 03 January 2002 07:53, Andrew W. Gaunt wrote: A fellow I work with inherited an HPUX machine and of course, nobody knows the root password. Does anyone know of a 'break in' procedure he can try? -Andy * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. * * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: HPUX break in
Thanks for the suggestions, he has sucessfully broken into the machine. What was the solution? * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: HPUX break in
He didn't elaborate, just that he found it using google's news group search. Michael O'Donnell wrote: [EMAIL PROTECTED]"> Thanks for the suggestions, he has sucessfully "broken" into the machine. What was the solution?*To unsubscribe from this list, send mail to [EMAIL PROTECTED]with the text 'unsubscribe gnhlug' in the message body.*
Re: Monadlug meeting
At http://news.gnhlug.org/article.php?sid=253 is: I''m going to try to come. Is there anything I can bring? * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: Bash question...
On Thu, 3 Jan 2002, Brian Chabot [EMAIL PROTECTED] wrote: Is there an easy way to tee the $HISTFILE to more than one location? What I want is a mirror of .bash_history stored elsewhere in case the It's probably not be the best way to proceed, but I have an LD_PRELOAD hack that tees writing to /dev/dsp to a temp file (i.e. to capture raw audio). I imagine it could be used to tee writes to ~/.bash_history. It's not clear to me one would want to interpose something as important /bin/bash via LD_PRELOAD... But you asked for easy, other options would seem to require modifying bash and/or kernel source. Another angle to consider is to turn on accounting. I've never used accouting (perhaps I played with it once Solaris long ago...) but I believe the system call is acct(2). * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: Bash question...
Is there an easy way to tee the $HISTFILE to more than one location? I believe that BASH history is only updated when the session ends rather than continuously during the session, so any session in which somebody messes with history logging will likely not be recorded. That being said, it might be possible (just thinking out loud here) to make your history file a named pipe (ie. FIFO). Then maybe some watcher-process could stare at it and copy any updates to the safe destination of your choice, preferably on another machine. If the bad guys delete the pipe this approach could fails, though, unless you also have that watcher-process silently put things back the way you want them if it notices that the attributes of the history file have changed. Also, if there's a perl/networking guru, I'm looking to re-write the trojan to look like it's working, but instead be logging the intruder's actions, IP, etc. It's a simple backdoor (only about 2.5 pages printed), so I might even be able to figure it out myself... Post a copy of the original here, please - it sounds interesting. Regards, Michael O'Donnell [EMAIL PROTECTED] ### # This transmission has not been approved # # by the Office of Homeland Security. # ### * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
[no subject]
Can you make a fake /dev/null? And make the real one /dev/.null or something? The normal one would go to a log file somewhere. You would have to change every program that uses it, but it might be worth it. Or is that something built in to the kernel? Just a thought from a clueless newbie... Rich Cloutier President, C*O SYSTEM SUPPORT SERVICES www.sysupport.com - Original Message - From: Brian Chabot [EMAIL PROTECTED] To: Greater NH Linux Users Group [EMAIL PROTECTED] Sent: Thursday, January 03, 2002 1:04 PM Subject: Bash question... After the recent breakins on my box, I've been writing a few watch scripts... One of the things the intruder did was to link his bash_history to /dev/null. My question is Is there an easy way to tee the $HISTFILE to more than one location? Basically, I doubt this %#^$%^ would be smart enough to have echo'd $HISTFILE, but rather just linked .bash_history as it was pretty commonly the $HISTFILE. What I want is a mirror of .bash_history stored elsewhere in case the original gets fubar'd. Also, if there's a perl/networking guru, I'm looking to re-write the trojan to look like it's working, but instead be logging the intruder's actions, IP, etc. It's a simple backdoor (only about 2.5 pages printed), so I might even be able to figure it out myself... Brian --- | [EMAIL PROTECTED]Spam me and DIE! | | http://www.datasquire.net | | Co-Founder Co-Owner of| | Data Squire Internet Services | --- * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. * * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
CD Labels
OK, not strictly Linux related but what do folks use to label CDs after burning them ? Has any tried a Sharpie(R) ? Do they ruin the lacquer ? TIA TomR * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: CD Labels
I've been using sharpies for years, and they work perfectly. Rich Cloutier President, C*O SYSTEM SUPPORT SERVICES www.sysupport.com - Original Message - From: Tom Rauschenbach [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 03, 2002 3:19 PM Subject: CD Labels OK, not strictly Linux related but what do folks use to label CDs after burning them ? Has any tried a Sharpie(R) ? Do they ruin the lacquer ? TIA TomR * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. * * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: CD Labels
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 3 Jan 2002, Tom Rauschenbach wrote: OK, not strictly Linux related but what do folks use to label CDs after burning them ? Has any tried a Sharpie(R) ? Do they ruin the lacquer ? This is one of the many reasons I carry a Sharpie with me at all times. I haven't noticed any problems using one on CDs, having done so literally hundreds of times. I have also used laser/inkjet labels with a CD Stomper or something similar. They're nice for making a (somewhat) more professional looking disc, but they're a bit pricey. - -- -Matt Come to think of it, there are already a million monkeys on a million typewriters, and Usenet is NOTHING like Shakespeare. -- Blair Houghton -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8NMAnc8/WFSz+GKMRAsS3AJ976xbMZ5KTCsZjEj84qOAkB3fFKQCffYts hatD8WgNfUR/9n3ls/2VE3U= =eU9R -END PGP SIGNATURE- * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: Bash question...
I'd prefer if the exploit wasn't posted on the mailing list or the web pages. We'd be accused of promoting that sort of thing, which I don't want to do - especially in the current political climate. He can mail it to the individuals who really want to see it. --Bruce Michael O'Donnell wrote: Is there an easy way to tee the $HISTFILE to more than one location? I believe that BASH history is only updated when the session ends rather than continuously during the session, so any session in which somebody messes with history logging will likely not be recorded. That being said, it might be possible (just thinking out loud here) to make your history file a named pipe (ie. FIFO). Then maybe some watcher-process could stare at it and copy any updates to the safe destination of your choice, preferably on another machine. If the bad guys delete the pipe this approach could fails, though, unless you also have that watcher-process silently put things back the way you want them if it notices that the attributes of the history file have changed. Also, if there's a perl/networking guru, I'm looking to re-write the trojan to look like it's working, but instead be logging the intruder's actions, IP, etc. It's a simple backdoor (only about 2.5 pages printed), so I might even be able to figure it out myself... Post a copy of the original here, please - it sounds interesting. Regards, Michael O'Donnell [EMAIL PROTECTED] ### # This transmission has not been approved # # by the Office of Homeland Security. # ### * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. * -- For the latest local Linux news, go to http://www.gnhlug.org/ . For the latest CodeMeta news, go to http://www.codemeta.com/news . For my personal news, go to http://www.milessmithfarm.net/news . * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: Bash question...
At http://news.gnhlug.org/article.php?sid=257 is: I''m assuming the cracker is coming in from the net. What about just running tcpdump against the port he''s coming in through (telnet?) and capture everything? * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: Monadlug meeting
At http://news.gnhlug.org/article.php?sid=253 is: Will people be gathering someplace beforehand for dinner or other decompression after a day of work and a week of holiday? * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: Apache/Expat/Sablotron
Well, first I'ld to thank all the respondents to this question. The key here was what I thought and what Kevin Clark mentioned explicitly: ONE consistent version of expat. Problem is, I'm wondering if revealing what the problem was will violate the DMCA. Seriously, given that 'strings' could be considered a circumvention device for binary only software. Now, I wonder if I've just given it away? ;-) ;-) nudge, nudge Truth is, I am royally pissed off that this problem wasted two weeks of my time and when it came right down to it, not a single piece of Free Software was at fault. Yet more reasons get even more in-the-face with my signature. Indirectly, maybe, but EVERY SINGLE PIECE of Free Software was doing the right thing. I do thank gnhlug for the help. It was much appreciated. On Thu, Jan 03, 2002 at 08:39:31AM -0500, Michael O'Donnell wrote: [snip] GPL all the way: Sell services, don't lease secrets Cool! Where do I send the bill? Awe, you got me. :-) Now if you only had me sign a contract with you first. Thanks for the help! On Wed, Jan 02, 2002 at 06:41:35PM -0500, Paul Iadonisi wrote: First, thank you to those who responded regarding my lost pgp passphrase. Maybe someday I'll find that little yellow sticky I wrote it on :-\ This is a tough problem we've been struggling with for about two weeks now, and I can't find the answer. Here's what works: OS: Red Hat 7.0 Apache: 1.3.14 (apparently an interim RH update no longer available) (looks like it is built with the supplied expat-lite) Cold Fusion: 4.5p2 Sablotron: 0.65 (dynamically linked to an external expat) And, of course our Cold Fusion code Our CF scripts call a custom tag written in C++ that uses sablotron Here's what doesn't work: OS: Red Hat 7.2 Apache: 1.3.22 (official update from RH) (built dynamically against supplied expat rpm) Cold Fusion: 5.0 Sablotron: 0.71 Expat: 1.95.1 (supplied with Red Hat 7.2) Our custom C++ tag is dying with a sig11 when called from our CF scripts, not when called from the command line via a C++ program. I've tried numerous things: Downgrading apache, downgrading sablotron back to 0.65, various combinations of statically and dynamically expat in apache and sablotron, and excluding it from linking alltogether. *sigh* Any ideas? -- -Paul Iadonisi Senior Systems Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. * -- -Paul Iadonisi Senior Systems Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: Apache/Expat/Sablotron
Problem is, I'm wondering if revealing what the problem was will violate the DMCA. We're very careful about these matters, you know - better to keep such dire knowledge to yourself... * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
