LINUX NEWS
RESOURCES & LINKS FROM BRAINBUZZ.COM
Thursday, September 13, 2001
Read By 7,000 Linux Enthusiasts Weekly!TABLE OF CONTENTS
1) Sean’s Notes
2) Linux News
Linux Running on Secure Cryptographic Coprocessor
SuSE's President Calls it Quits
Watch Out for the x.c Worm
DMCA, eh?3) Linux Resources
Big Endian? Little Endian?
Billion Second Bug
Lots of Exploits
Using the GNU Tools for Software Development
UNIX and Programming Quotes4) App o’ the week
~~~~~~~~~~~~~~~~~~~~~~ ADVERTISEMENT ~~~~~~~~~~~~~~~~~~~~~~~
Gain study time and enhance your learning! Hear hundreds of certification exam questions on audio CD or cassettes. Learn while you commute to and from work, exercise, or walk the dog. Ideal for those times when you can’t read. 90-day money back guarantee if you are not happy.
http://ad.brainbuzz.com/?RC06&AI%47
For information on how to advertise in this newsletter
please contact mailto:adsales@BrainBuzz.com or visit
http://cramsession.brainbuzz.com/marketing/default.asp
-------------------------
1) Sean's Notes
-------------------------
I have to wonder if I'm getting lazy. When I first started
out with Unix, I would download everything in source form
and compile it -- no binaries. This had some advantages:
- fewer conflicts
- control over where files go and what options were selected
- didn't have to trust an unknown binary
These days, though, I find myself preferring to download an
RPM package:
- much easier
- system keeps track of what files belong to what package
- much faster, especially with multiple updates
The conflicts I can deal with... Every so often, *cough*
snort, gd, libc *cough* a package is dead set on a particular
version of a library, so I'll download the source rpm and
rebuild it on my system:
rpm --rebuild package.src.rpm
or even go as far as editing the .spec file to change the
options before I compile.
The advantage is the management you get with a packaging
system. No more asking yourself what that file does, or
trying to figure out how to get rid of that application that
strews files all over.
rpm -qf /path/to/file
rpm -qil packagename
How about the security aspect? With the source, I can check
for naughty things. With a binary, I have to trust the guy
who compiled it. Wait a sec, though... Am I going to go
through every line of code looking for stuff that might do
bad things? Not likely! Even then, there is no guarantee
I'll find it, or that fixing it will have any effect.
Take for example a classic example from Unix history. Ken
Thompson, one of the creators of Unix, once inserted a bug
into the login program. With a special username and
password, anyone could log in as root. But with the source
code to login.c, anyone could find that, fix it, and
recompile it...assuming you can trust the compiler.
Having also been in on the development of the compiler, he
modified it so that it would recognize when it was compiling
login.c, and insert the bug even if it wasn't in the source
code.
How about fixing the source code to the compiler?
To do that, you'd need the compiler to compile the compiler
source. Which had another bug in it. Guess what that did?
That's right. Re-insert the compiler bugs. With that done,
though, the compiler source didn't even need the bug in it.
If someone recompiled it, the binary compiler would just
add in the bug. Pretty clever, if you ask me, and it's a
great demonstration of how the transitive aspect of trust
can hurt you. He wrote it up in a paper called "Reflections
on Trusting Trust", and is worth a read.
http://www.acm.org/classics/sep95/
There's also no guarantee the source hasn't been tampered
with by crackers. For a very brief period of time, the main
distribution site of the TCP Wrappers was hacked, and a
trojan inserted into the source.
But, "since I can't trust anyone, I'll do what's easiest"
won't fly in my books. When downloading binaries, I try to
get them from larger sites, so anything funny will have a
greater chance of being noticed. Depending on the program,
taking some extra precautions such as running it as its own
user, or using the strace program to watch it may be
warranted.
If you do download stuff from questionable sources (and
some good programs have come from them), you may want to
grab the source and give it a quick scan. Look for "printf"
strings, if you see something like
printf("I own your system!!!\n");
that's a bad thing. Strings like "unlink" (remove files),
"sendmail" and "mail" (trying to mail out password files),
and such should be setting off warning bells. Also, no
matter what, I always look at shell scripts that are
provided by source or binary packages. Not only is it the
easiest place to put a trojan, it's also a good way to
figure out where all the files are going to be installed.
So, maybe I'm not lazy, I'm just...efficient. Binary
packages offer package management and are much easier.
Source packages require extra work to compile, even more
to put under package management, but offer more flexibility.
Before I sign off, I would like to send my condolences to
those who suffered the loss of loved ones in Tuesday's
disasters, and to wish the best to those who are working
at repairing the damage and finding answers.
Long live the Penguin,
Sean
mailto:swalberg@brainbuzz.com
Visit the Linux News Board at
http://boards.brainbuzz.com/boards/vbt.asp?b2
-------------------------
2) Linux News
-------------------------
-------------------------------------------------
Linux Running on Secure Cryptographic Coprocessor
-------------------------------------------------
Small, isolated devices are nothing new to Linux. IBM has a
coprocessor called the 4758, which is a tamper sensing
secure processor designed for high security devices. Usually
used with a proprietary operating system, IBM hacked Linux
to run on it, giving developers a new target and getting
more features out of the device itself.
http://researchweb.watson.ibm.com/resources/news/20010828_mycroft.s
html
-------------------------------
SuSE's President Calls it Quits
-------------------------------
SuSE, a German based distribution, has garnered a lot of
support from the community, likely due to its ease of use
and powerful add-on tools. This press release announces the
stepping down of the President, and calls for a positive
outlook on the future.
http://www.suse.com/us/suse/news/PressReleases/hohndel.html
--------------------------
Watch Out for the x.c Worm
--------------------------
Ignoring all the "This could be the next Code Red" hype, BSD
and Solaris users should take note. There was a buffer
overflow in in.telnetd (the telnet daemon) which this worm
takes advantage of. But you're not worried, are you? You
use TCP wrappers to limit telnet access from only trusted
hosts, or replace it entirely with ssh.
http://www.zdnet.com/zdnn/stories/news/0,4586,2811517,00.html
---------
DMCA, eh?
---------
You've all heard me rant about the Digital Millennium
Copyright Act, and how it stomps on the rights of people,
and can be used to attack Open Source. If you thought you
were safe because you don't live in the States, think again
...Canada is looking to enact much the same legislation.
http://www.eff.org/alerts/20010907_eff_canada_cpdci_alert.html
-------------------------
3) Linux Resources
-------------------------
--------------------------
Big Endian? Little Endian?
--------------------------
Heard the term "Endian", and didn't know what it means?
Well, you're using an operating system that can run across
systems of different Endian-ess, so you really want to read
this article. For those that do any programming, this is an
essential concept to master, since it can introduce subtle
bugs if not taken care of.
http://www.cs.umass.edu/~verts/cs32/endian.html
-------------------
Billion Second Bug
-------------------
So the Billion Second anniversary went off without a hitch
...almost. OpenLDAP's replication daemon, slurpd, decided
not to store the time as an integer, and wasn't prepared for
the extra digit. Tsk, tsk. The fixes are in CVS, or watch
the page for a new release.
http://www.openldap.org
-------------------
Lots of Exploits
-------------------
Interested in what tools the bad guys use to hack into
systems? This page offers a well-organized list of exploits,
along with the source code. Studying the code is also a good
way to learn security techniques. Be careful (and lawful)!
http://www.cotse.com/linux.htm
--------------------------------------------
Using the GNU Tools for Software Development
--------------------------------------------
As we all know, Linux uses a free compiler called GCC. You
may also know about some of the other tools, like make,
autoconf, automake, the debugger, and the profiler. If not,
you'll find out about them in this article.
http://www.linux.com/learn/newsitem.phtml?sid=1&aid522
---------------------------
UNIX and Programming Quotes
---------------------------
This is a page chock full of good quotes from Larry Wall,
alt.sysadmin.recovery, and many more popular places. Most
have to do with UNIX, programming, or making fun of MS.
One of my faves? "If NT is the answer, you don't understand
the question."
http://www.it-umschueler.de/luebeck/public/humor/quotes.htm
-------------------------
4) App o' the week
-------------------------
RFCs (Request For Comments) define the Internet. Need to
know how a protocol works? Chances are, there are RFCs
dealing with it. Rather than using a web browser, this
command line utility lets you search and read RFCs from a
console session, which ends up being a fair bit faster than
over the web.
http://www.dewn.com/rfc/
-------------------------
(C) 2001 BrainBuzz.com. All Rights Reserved.
-------------------------
-------------------------
This message is from BrainBuzz.com.
You are currently subscribed to the
Hottest Linux News and Resources
as: sean@ertw.com
To un-subscribe from this newsletter by e-mail:
send a blank email message to:
mailto:leave-linuxnews-3825955Y@list.cramsession.com
-------------------------------------------------------
To Subscribe to this newsletter by e-mail:
send a blank email message to:
mailto:join-linuxnews@list.brainbuzz.com
-------------------------