Slashdot Mirror
Remote Root Exploit in CVS
RenHoek writes "Security expert Stefan Esser from E-matters discovered a bug in CVS version 1.11.4 and lower, that can give malignant users remote root access. The exploit was confirmed on BSD, but other OS's like Linux, Solaris and Windows are vulnerable too. A security advisory can be found here and there is also a patch available. CVS version 1.11.5 which is fixed can be downloaded as well."
now anyone can get in my backdoor..... (someone had to say it)
This kind of thing always seems to happen after I burn a new release of something.
Sigh...
Life is the leading cause of death in America.
I think "Malicious" is the more... conventional choice.
-=Best Viewed Using [INLINE]=-
Sounds like a good way to alter the code stored on a hacked machine to install backdoors for you to get into others.
Do you OSS folks actually read through every line of source before you build something big like Apache or Squid or SAMBA, just to make sure noone has altered the code?
I don't need no instructions to know how to rock!!!!
So if CVS is in CVS, maybe somebody rooted CVS's CVS to apply a patch to backdoor CVS, even with new CVS patches to CVS? ;)
cant you guys read? It is an additional patch!
The patch from e-matters does NOT fix the double free bug!!!!
ah yes, another representation of sofware's circle of life.
exploit, patch, exploit, patch, exploit, patch.
insert elton john music here
Karma: Raspberry Kiwi
According to this post on the Full-Disclosure list, the CVS bug has been known underground for a while. Wonder what they've been doing with it?
Yea, I used CVS to update my mplayer so I could watch some newer Windows Media files sent to be by some nice young woman at "Brintey_XXX_Hot_NAKED_ J-LO_CAUGHT_ACTION@hotmail.com". Shortly thereafter, I came back from the bathroom to discover that my desktop image was replaced by a big penis with the KDE gears for testicles, and I couldn't start any programs.
What fool runs their cvs pserver as root? Every installation I've ever seen has it running as a non-privelidged user. While of course any remote compromise is not good, lets not exagerate the severity of this problem.
Using your sig line to advertise for friends is lame.
When you look at all the expolits in commercial software and then compare them to the amount found in free software you will see what I mean. I used to be a big Microsoft fan until I looked at all the money I save with free Gnu/BSD/linux software and now I never look back.
All the best,
--Achmed
Swaribabu Consulting Inc. -- We code so you don't have to
I wonder how you operate to remove those?
Note to M1-ers: a curt but otherwise insightful message is not "Flamebait" or "Troll".
A porpoise? What do I need a dolphin for?
I thought this affected Windows also......
D.A.K.D.A.E.---- Deny all Knowledge, Destroy All Evidence
Good thing I use Linux because Windows is so... Oh, nevermind.
I think it's time to give up on C for most Internet application development, and use languages which eliminate this wide class of bugs. Banning C altogether is of course an overstatement, but C code in an application should be treated like setuid code. There should be as little of it as possible (the occasional optimized inner loop of something, for example), and it needs to be scrutinized very carefully before deployment.
Anyone know what language Subversion is written in?
No one had to say it. But you went ahead and said it anyway. Now look at yourself.
I'd say part of sensible planning is trying to lower the effect of accidents (or bugs), even if you can't prevent all of them. That means wearing the seat belts in your car, and using array checking and garbage collection in your programs.
This problem wouldnt happen if you were using a commercial product.
This should answer your question.
errrr... Look at their track records. I'd trust what Linus was doing more than I would Bill.
It's not as bad as that; most local exploits will only give you the same privileges that you already have, not elevate them. For example, the mutt hole made it possible for certain data items to run code as the same user that is running mutt. There are very few programs that are allowed to run with superuser privileges, and those packages should be kept to an absolute minimum. CVS, Apache, samba, ftpd and their like should NEVER run with root privileges; at worst a daemon may need permission to open a privileged port, but then relinquish such privleges. At best, they run in a chroot'd environment (like any FTP server that accepts incomming requests...).
The wheel is turning, but the hamster is dead.
The point is software is about tradeoffs. Take Windows 95, for example. Any time something becomes corrupted, you get a Blue Screen. If MS wanted to prevent the bug from spreading and corrupting anything else, they'd reboot immediately. But people are willing to take the risk of running with a potentially unstable system because there are advantages: the risk of further bugs is small, I'd like to save the document I've been working on the past three hours, or it's just not worth my time to wait through a reboot.
Choosing C is about tradeoffs too. Coding in C means you get a fast language that produces a well-understood output. And you are also very sure that no language vendor is ever going to change the underlying behavior and break your code. Plus, the C source can be compiled and run on practically every OS out there with minimal overhead.
The person who writes the software gets to decide where the software sits on this tradeoff. If you disagree, you are free to write your own server in whatever language you want.
A witty [sig] proves nothing. --Voltaire
I became a GCC maintainer for precisely this reason.
And I'll just say to you, pclminion, that those JPGs in your home directory aren't as, ahem, secure as you'd like to think.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Bashing goto is so tired. It's a great construct for a procedural language. As someone above pointed out, most languages (even the LISP I championed earlier) are written in C. Well, C is "written" in assembly, and all assembly has is goto. Not to mention the performance advantages goto can offer over more structured control flow (for evidence, grep -r goto /usr/src/linux ).
Maybe goto is counter to the spirit of object-orientation, but then again "OO" and "Procedural" are orthogonal when you get right down to it: C++ is OO and procedural and Haskell can be OO but is not procedural.
Goto is not the enemy!
All's true that is mistrusted
This post is severely uninformed, like most others that defend C for network applications. Here's why.
...) does."
) . For well optimized code, that number can easily be within 20%. Of course, writing in a high level language gives you more time to work on better algorithms, which as any good programmer knows, is what *really* matters in its performance.
o m7misc/net/mlftpd/). It took me only about a weekend and the result was about 10% the length of the C program. It also saturates my 100mbit link without using more than a few percent of my crappy 400mhz CPU. (It transfers data using basically the same mechanisms that C uses, so C doesn't have any advantage in that part.) Most importantly, I sleep tighter at night knowing that my server is 100% buffer overflow, double-free, and integer overflow free.
- "Java would probably crash with some sort of exception instead of happily running in an invalid state... but do you really
want anyone to remotely crash the server daemon either?"
No, of course not, but that's about ten million times better than giving the attacker remote root access. Script kiddies don't get much out of crashing servers, but they do out of compromising a computer. And it is much much harder to detect and clean up afterwards.
- "C is absolutely, bar none, the fastest language for slinging raw bytes around (err... ignoring assembly, but it's close) -
and that's pretty much what a CVS server (or FTP, or HTTP, or
Wrong. Most server programs are network and disk-bound, *not* CPU bound. (In fact, I believe that CVS spends most of its CPU time doing diffs, that is, text processing--something that C is notoriously awful at.) Most users wouldn't notice if their CVS server used 20 times more CPU. C is no more than 2x faster than modern safe languages like O'Caml and SML (http://www.bagley.org/~doug/shootout/craps.shtml
I'm not just bullshitting, either: Last summer after another wu_ftpd remote hole I rewrote the damn thing in SML (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/t
- "... the bug here isn't a memory management bug. It's a flawed PROGRAM design that RESULTS IN a memory management bug."
Unfortunately, C encourages such bad program design, and then makes bugs deadly. How else can you explain so many buffer overflows, double-frees, and integer overflows? Don't tell me it's the programmers, because almost all of the most revered C software, written by the most talented programmers I know, has had such bugs. (Quake III, ssh, linux kernel, wu_ftpd, apache, perl, etc., etc., etc.)
Well I guess that makes all VB coders geniuses then, since they never get buffer overflows. They must just be the greatest bunch of programmers around.
Seriously, that's a stupid attitude to have. When you're talking about security, you have to assume the worst from the start. That means assuming coders will make mistakes, no matter how good they are. Even the best coders do make mistakes. In a language designed to be secure, the impact of coding mistakes is minimized.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
> Again, the problem is not the language, it's the coder. ... Don't blame a language for operating exactly as it's designed to.
p ache
I blame the language. The reason is this: C makes it so easy, and so dangerous, to make such bugs, that they are extremely common, even among the best programmers. I challenge you to explain why some of the most revered software created by some of the most revered C hackers has had buffer overflows, if it's not the language's fault:
Quake I, II, and III
Linux Kernel, OpenBSD Kernel, FreeBSD Kernel
SSH
perl
Half-Life
X11
BIND
dhcpd
a
mozilla, internet explorer, netscape navigator, konqueror, opera
etc.
etc.
etc.
etc.
(Things like the operating system kernels are not so easy to rewrite in a modern safe language, but network daemons are an *obvious choice* and are also the most dangerous!!)
By the way, C garbage collection is crappy compared to built in support in a modern language: It needs to be conservative, and can't compact the heap. (Of course, that doesn't stop the authors of gcc from using it!)
Many "functional" languages (like SML and O'Caml) have imperative features for exactly this reason, just as C has (sort of) the ability to pass around functions. It's true that Haskell (purely functional) is not a great language to write I/O intensive software in (though Haskell has its own ways to do IO, and Haskell fans have written many I/O intensive, interactive applications, including network daemons). However, Haskell would be far from the worst language, because at least you'd have a better chance of ending up with a program that works correctly (doesn't provide remote root access to anyone).
I maintain that SML and O'Caml ("functional" languages) are utterly practical (and in fact superior to C and C++ in terms of correctness and ease of use) for network software. I've written a full-featured ftp server in SML to replace my buggy wu_ftpd, so I have some evidence to back this up.
Holy screaming fuckmonkeys, Batman. You have no idea how much work we/they go through to ensure that GCC is buildable by anything even resembling a C compiler. (I say "we/they" because I generally don't have to worry about it in my little corner of the world.)
GCC was intended from its earliest days to replace whatever native (proprietary) compiler came with or was sold for your native (proprietary, evil, etc) Unix platform. When you build GCC, it actually is built three times:
Copy #3 is then used to build the rest of the compiler (other languages) and the runtime libraries. Copy #3 is what gets installed on your system.
Huge chunks of the GCC source are still maintained in K&R C for those platforms which don't have an ISO (ANSI) C compiler. Chunks of the standard C library have homegrown replacements inside GCC, for those platforms which aren't ANSI/POSIX.
Fortunately, the number of those systems has dwindled, but at one time they were the majority.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Well I guess that makes all VB coders geniuses then, since they never get buffer overflows. They must just be the greatest bunch of programmers around.
It's just hard to kill people when you are driving a go-cart in a predefined track.
That means assuming coders will make mistakes, no matter how good they are. Even the best coders do make mistakes. In a language designed to be secure, the impact of coding mistakes is minimized.
C was never designed to be secure. Blame C programmers for insecure code, not the language. There are plenty of steps you can take to ensure safe C code. If you expect a secure application, and you use C, than take the proper steps to make it secure. It's user error.
It's not a stupid attitude, it's a philosophical attitude. I'm not defending C, but it works exactly as designed. End of story.
Dacels Jewelers can't be trusted.
There is enough blame for everyone. When a C programmer makes a mistake, he deserves some of the blame. But if the language is inherently insecure, it is also partly the fault of the language. The way you're talking, we should just all use C for our secure code and punish programmers when they make mistakes because it's their fault. Instead you can realize that part of the fault is with the language and replace the language. Even though C wasn't designed to be secure you can still blame it for security related problems.
In the end, the semantics of the word "blame" aren't important. The important thing is that people realize that C programmers make security mistakes because C is an insecure language, and don't use C in security-critical areas, or review security-related C code extremely thoroughly before release.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
But if the language is inherently insecure, it is also partly the fault of the language.
Ok, the language isn't insecure... well, you can make it secure, and have setuid wrappers on all your scripts and have a truly secure implementation. It would constrict freedom. The language allows people to write insecure code. All the recent SSH notifications on CERT were implementation, and not C-specific problems.
The important thing is that people realize that C programmers make security mistakes because C is an insecure language, and don't use C in security-critical areas, or review security-related C code extremely thoroughly before release.
C programmers make mistakes because they get lazy and don't properly audit their code. After every function you write, simply give it another good look and make sure it cleans up after itself, and maintains proper design. It's perfectly fine then. Like I said in another comment, I've worked on a project that had a bit over 600K lines. You could have done the same in about 250K or so, but it was 600K because everything was modularized. Taking design queues from Knuth, it was extremely robust and very stable. No memory leaks, no buffer overflow problems. Everything that got alloc'd actually had a comment where the variable would get free'd at.
It's called good design of software, not good design of language.
Dacels Jewelers can't be trusted.
it's a philosophical attitude. I'm not defending C, but it works exactly as designed
The 'philosophy' is prehistoric, dating from When Men Were Men and You Paid Per Cycle and Bad Input Dumped Core.
Given that all the assumptions have changed, it's strange that there's so many defenders. Could it be that people used C, because until 3-4 years ago on a GNU system, that was the best you had?
Someone asked what I'd recommend instead of C. I don't know. I don't think there's a One True Language. Lately I'm coding in Python and like it, though it has its own shortcomings. Java is C-like enough to be comfortable for today's C and C++ programmers. I like the Java language but despise the runtime systems that are usually shipped with it. Perl seems like a monstrosity to me (awk with cancer) but with the -T option (taint checking), it, too, saves you from making a lot of bugs that are easy to miss when writing a C program.
If you've ever written setuid code (at least responsibly), you know the feeling of paranoia and vigilance you have to bring to every line of it that you write. I'm very skeptical if you tell me you bring the same paranoia to all the code you write. Of course there's no magic bullet to secure programming, but there are tools available (i.e. languages with fewer exposed sharp edges) that provide various kinds of safety nets that can rescue you a sizeable percentage of the time. It's foolish not to use those tools.
Java isn't any less "free" than C even though it is a much more secure language. It is just as turing-complete as C is. If you use a language with security features built in you spend less time auditing and more time being productive. As we all know, programmer time is more expensive than CPU time, so a little less efficiency is excusable. Even so, the technology behind new languages is maturing to the point where it's hard to tell the difference anymore.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
The "closed source" classic mac is 100% secure. Its never had a remote exploit discoverred. Also this CVS exploit affects LINUX not just BSD.
:
I think its ironic that with every remote security hole and exploit, including the few that affect a majority of BSD installations, no one is addressing the fact that there are more secure platforms for webserving. Instead of focusing on the porous unix/linux offerings, or MS weaknesses.
It is a concrete fact that that no MacOS based webserver has ever been hacked into in the history of the internet.
The MacOS running WebStar and other webservers as has never been exploited or defaced, and are are unbreakable based on historical evidence.
In fact in the entire SecurityFocus (BugTraq) database history there has never been a Mac exploited over the internet remotely.
That is why the US Army gave up on MS IIS and got a Mac for a web server.
I am not talking about FreeBSD derived MacOS X (which already had a more than a 30 exploits and potential exploits ) I am talking about current Mac OS 9.x and earlier. Apples Mac OS 9.2.2 is latest and came out rhis last summer. According to Google HTTP requests, Mac OS 9 users outnumber Mac OS X almost 9 to 1. Luckily for them they are all secure.
Why is is hack proof? These reasons
1> No command shell. No shell means no way to hook or intercept the flow of control with many various shell oriented tricks found in Unix or NT. Apple uses an object model for process to process communication that is heavily typed and "pipe-less"
2> No Root user. All Mac developers know their code is always running at root. Nothing is higher (except undocumented microkernel stuff where you pass Gary Davidians birthday into certain registers and make a special call). By always being root there is no false sense of security, and programming is done carefully.
3> Pascal strings. ANSI C Strings are the number one way people exploit Linux and Wintel boxes. The Mac avoids C strings historically in most of all of its OS. In fact even its ROMs originally used Pascal strings. As you know Pascal strings (length prefixed) are faster than C (because they have the length delimiter in the front and do not have to endlessly hunt for NULL), but the side effect is less buffer exploits. Individual 3rd party products may use C stings and bind to ANSI libraries, but many do not. In case you are not aware of what a "pascal string" is, it usually has no null byte terminator.
4> Macs running Webstar have ability to only run CGI placed in correct directory location and correctly file "typed" (not mere file name extension). File types on Macs are not easily settable by users, especially remotely. Apache as you know has had many problems in earlier years preventing wayward execution.
5> Macs never run code ever merely based on how a file is named. ".exe" suffixes mean nothing! For example the file type is 4 characters of user-invisible attributes, along with many other invisible attributes, but these 4 bytes cannot be set by most tool oriented utilities that work with data files. For example file copy utilities preserve launchable file-types, but JPEG MPEG HTML TXT etc oriented tools are physically incapable by design of creating an executable file. The file type is not set to executable for hte hackers needs. In fact its even more secure than that. A mac cannot run a program unless it has TWO files. The second file is an invisible file associated with the data fork file and is called a resource fork. EVERY mac program has a resource fork file containing launch information. It needs to be present. Typically JPEG, HTML, MPEG, TXT, ZIP, C, etc are merely data files and lack resource fork files, and even if the y had them they would lack launch information. but the best part is that mac web programs and server tools do not create files with resource forks usually. TOTAL security.
4> Stack return address positioned in safer location than some intel Osses. Buffer exploits take advantage of loser programmers lack of string length checking and clobber the return address to run thier exploit code instead. The Mac compilers usually place return address in front or out of context of where the buffer would overrun. Much safer.
7> There are less macs, though there are huge cash prizes for cracking into a MacOS based WebStar server (typically over $10,000 US). Less macs means less hacker interest, but there are MILLIONS of macs sold, and some of the most skilled programmers are well versed in systems level mac engineering and know of the cash prizes, so its a moot point, but perhaps macs are never kracked because there appear to be less of them. (many macs pretend they are unix and give false headers to requests to keep up the illusion, ftp http, finger, etc). But some huge high performance sites use load-balancing webstar. Regardless, no mac has ever been rooted in history of the internet, except with a strange 3rd party tool in 1995.
8> MacOS source not available traditionally, except within apple, similar to Microsoft source only available to its summer interns and engineers, source is rare to MacOS. This makes it hard to look for programming mistakes, but I feel the restricted source access is not the main reasons the MacOS has never been remotely broken into and exploited.
Sure a fool can install freeware and shareware server tools and unsecure 3rd party addon tools for e-commerce, but a mac (MacOS 9) running WebStar is the most secure web server possible and webstar offers many services as is.
One 3rd party tool created the only known exploit backdoor in mac history and that was back in 1996 (7?) and is not, nor was, a widely used tool. I do not even know its name. From 1995 to 2002 not one macintosh web server on the internet has been broken into or defaced EVER. Other than that event or a rouge 3rd party CGI tool ages ago in 1996 (7?), no mac web server has ever been rooted,defaced,owned,scanned,exploited, etc. They few mistaken defacements recently attributed to Mac OS are actually Mac OS X (unix) events.
Mac programmers do not like CVS and prefer 10 year old legacy multimillion dollar quality tools like SourceSafe. Admittedly SourceSafe is a little slower than CVS in some benchmarks but it understands multiforks, resources, binaries, etc better and first and is better for highly collaborative use. (It locks text files, etc, and tries to avoid clobbering). It also merges better with clobberred files. But the BEST part of SourceSafe is that DOES NOT USE a single tcp/ip call directly or at all. Secure networking is allowed.
This CVS bug was by use of ANSI C library and "malloc"... something alsmot NO commercial mac products use. (Macintosh users use Mac OS routines to create memory, somtimes movable memory via handles)
I think its quite amusing that there are over 200 or 300 known remote exploit vulnerabilities in RedHat over the years and not one MacOS 9.x or older remote exploit hack. There are even vulnerabilities a month ago in OpenBSD! Each month vulnerabilities in XP arise.
Not one remote exploit. And that includes Webstar and other web servers on the Mac.
A rare set of documentation tutorials and exercises on rewriting all buffer LINUX exploits from INTEL to PowerPC was published less than a year ago. The priceless hacker tutorials were by a linux fanatic : Christopher A Shepherd, 3036 Foxhill Circle #102, Apopka, FL 32703 and he wrote the tutorials in a context against BSD-Mach Mac OSX. but all of his unix methods will find little to exploit on a traditional MacOS server.
BTW this is NOT an add for webstar.. the recent versions of webstar sold for over the last year are insecure and cannot run on Mac OS 9.x or 8.x, and only run on the repeatedly exploited MacOS X.
--- too bad the linux community is so stubborn that they refuse to understand that the Mac has always been the most secure OS for servers.
BugTraq concurs! As does the WWW consortium.
Just use a Mac, as many colleges and large media sites do, and most commercial airlines for there in-house security.
I am well aware that in theory transaction turnaround time might suffer a little under excessive loads if you do not use load balancing machines, but a 25% speedup is hardly worth it in comparison to years and years of hacker-proof history.
This had to be reposted because of an anti-mac bigot. I also think its funny that people who hate the mac always moderate 100% factual and highly detailed informative posts as -1 ALWAYS. Thats one of the most predictable aspects of a unix-lover's actions... simple intolerance of new ideas.
If you are using Debian, you should add security.debian.org to your package source list. As usual with most problems like this, a patched version has already been released. Take a look at http://www.debian.org/security/ for more info on how to set your system up to take advantage of security patches.
C on Mac is secure (mac people avoid malloc and avoid ANSI C strings etc).
:
I think its ironic that with every remote security hole and exploit, including the few that affect a majority of BSD and Linux installations (this bug affected Linux too), no one is addressing the fact that there are more secure platforms for webserving. Instead of focusing on the porous unix/linux offerings, or MS weaknesses.
It is a concrete fact that that no MacOS based webserver has ever been hacked into in the history of the internet.
The MacOS running WebStar and other webservers as has never been exploited or defaced, and are are unbreakable based on historical evidence.
In fact in the entire SecurityFocus (BugTraq) database history there has never been a Mac exploited over the internet remotely.
That is why the US Army gave up on MS IIS and got a Mac for a web server.
I am not talking about FreeBSD derived MacOS X (which already had a more than a 30 exploits and potential exploits ) I am talking about current Mac OS 9.x and earlier. Apples Mac OS 9.2.2 is latest and came out rhis last summer. According to Google HTTP requests, Mac OS 9 users outnumber Mac OS X almost 9 to 1. Luckily for them they are all secure.
Why is is hack proof? These reasons
1> No command shell. No shell means no way to hook or intercept the flow of control with many various shell oriented tricks found in Unix or NT. Apple uses an object model for process to process communication that is heavily typed and "pipe-less"
2> No Root user. All Mac developers know their code is always running at root. Nothing is higher (except undocumented microkernel stuff where you pass Gary Davidians birthday into certain registers and make a special call). By always being root there is no false sense of security, and programming is done carefully.
3> Pascal strings. ANSI C Strings are the number one way people exploit Linux and Wintel boxes. The Mac avoids C strings historically in most of all of its OS. In fact even its ROMs originally used Pascal strings. As you know Pascal strings (length prefixed) are faster than C (because they have the length delimiter in the front and do not have to endlessly hunt for NULL), but the side effect is less buffer exploits. Individual 3rd party products may use C stings and bind to ANSI libraries, but many do not. In case you are not aware of what a "pascal string" is, it usually has no null byte terminator.
4> Macs running Webstar have ability to only run CGI placed in correct directory location and correctly file "typed" (not mere file name extension). File types on Macs are not easily settable by users, especially remotely. Apache as you know has had many problems in earlier years preventing wayward execution.
5> Macs never run code ever merely based on how a file is named. ".exe" suffixes mean nothing! For example the file type is 4 characters of user-invisible attributes, along with many other invisible attributes, but these 4 bytes cannot be set by most tool oriented utilities that work with data files. For example file copy utilities preserve launchable file-types, but JPEG MPEG HTML TXT etc oriented tools are physically incapable by design of creating an executable file. The file type is not set to executable for hte hackers needs. In fact its even more secure than that. A mac cannot run a program unless it has TWO files. The second file is an invisible file associated with the data fork file and is called a resource fork. EVERY mac program has a resource fork file containing launch information. It needs to be present. Typically JPEG, HTML, MPEG, TXT, ZIP, C, etc are merely data files and lack resource fork files, and even if the y had them they would lack launch information. but the best part is that mac web programs and server tools do not create files with resource forks usually. TOTAL security.
4> Stack return address positioned in safer location than some intel Osses. Buffer exploits take advantage of loser programmers lack of string length checking and clobber the return address to run thier exploit code instead. The Mac compilers usually place return address in front or out of context of where the buffer would overrun. Much safer.
7> There are less macs, though there are huge cash prizes for cracking into a MacOS based WebStar server (typically over $10,000 US). Less macs means less hacker interest, but there are MILLIONS of macs sold, and some of the most skilled programmers are well versed in systems level mac engineering and know of the cash prizes, so its a moot point, but perhaps macs are never kracked because there appear to be less of them. (many macs pretend they are unix and give false headers to requests to keep up the illusion, ftp http, finger, etc). But some huge high performance sites use load-balancing webstar. Regardless, no mac has ever been rooted in history of the internet, except with a strange 3rd party tool in 1995.
8> MacOS source not available traditionally, except within apple, similar to Microsoft source only available to its summer interns and engineers, source is rare to MacOS. This makes it hard to look for programming mistakes, but I feel the restricted source access is not the main reasons the MacOS has never been remotely broken into and exploited.
Sure a fool can install freeware and shareware server tools and unsecure 3rd party addon tools for e-commerce, but a mac (MacOS 9) running WebStar is the most secure web server possible and webstar offers many services as is.
One 3rd party tool created the only known exploit backdoor in mac history and that was back in 1996 (7?) and is not, nor was, a widely used tool. I do not even know its name. From 1995 to 2002 not one macintosh web server on the internet has been broken into or defaced EVER. Other than that event or a rouge 3rd party CGI tool ages ago in 1996 (7?), no mac web server has ever been rooted,defaced,owned,scanned,exploited, etc. They few mistaken defacements recently attributed to Mac OS are actually Mac OS X (unix) events.
Mac programmers do not like CVS and prefer 10 year old legacy multimillion dollar quality tools like SourceSafe. Admittedly SourceSafe is a little slower than CVS in some benchmarks but it understands multiforks, resources, binaries, etc better and first and is better for highly collaborative use. (It locks text files, etc, and tries to avoid clobbering). It also merges better with clobberred files. But the BEST part of SourceSafe is that DOES NOT USE a single tcp/ip call directly or at all. Secure networking is allowed.
This CVS bug was by use of ANSI C library and "malloc"... something alsmot NO commercial mac products use. (Macintosh users use Mac OS routines to create memory, somtimes movable memory via handles)
I think its quite amusing that there are over 200 or 300 known remote exploit vulnerabilities in RedHat over the years and not one MacOS 9.x or older remote exploit hack. There are even vulnerabilities a month ago in OpenBSD! Each month vulnerabilities in XP arise.
Not one remote exploit. And that includes Webstar and other web servers on the Mac.
A rare set of documentation tutorials and exercises on rewriting all buffer LINUX exploits from INTEL to PowerPC was published less than a year ago. The priceless hacker tutorials were by a linux fanatic : Christopher A Shepherd, 3036 Foxhill Circle #102, Apopka, FL 32703 and he wrote the tutorials in a context against BSD-Mach Mac OSX. but all of his unix methods will find little to exploit on a traditional MacOS server.
BTW this is NOT an add for webstar.. the recent versions of webstar sold for over the last year are insecure and cannot run on Mac OS 9.x or 8.x, and only run on the repeatedly exploited MacOS X.
--- too bad the linux community is so stubborn that they refuse to understand that the Mac has always been the most secure OS for servers.
BugTraq concurs! As does the WWW consortium.
Just use a Mac, as many colleges and large media sites do, and most commercial airlines for there in-house security.
I am well aware that in theory transaction turnaround time might suffer a little under excessive loads if you do not use load balancing machines, but a 25% speedup is hardly worth it in comparison to years and years of hacker-proof history.
This had to be reposted because of an anti-mac bigot. I also think its funny that people who hate the mac always moderate 100% factual and highly detailed informative posts as -1 ALWAYS. Thats one of the most predictable aspects of a unix-lover's actions... simple intolerance of new ideas.
I'm aware of your ftp server. I'm also aware that it is the only one of its kind. Why don't you write some more software and compete to determine which is better.
How we know is more important than what we know.
It's also a concrete fact that there are only 6 of those polluting the Internet, so let's not go into comparisons.
[btw, your crapflooding is getting tiresome, especially when it's so stupid]
Well, I don't think it's the only one of its kind. For instance, the fox project at CMU wrote an entire TCP/IP network stack and web server in SML. (However, I may be the only one who thinks his software is practical enough for regular users to run, and who can stomach slashdot enough to try to convince others that it is a good way to go.) Anyway, when I get time I do try to write more software... I have ported some of the other simple (useless) daemons, and I've done some work on an ssh daemon too.
And it seems to me, your stack got hacked
By a buffer overflow.
You're never fixed by patches,
'Cause you still free() twice.
And I would try not to install you,
If I had another choice.
cvs diff you now,
And hope they don't get r00t.
Sorry but "normal" builds of gcc like configure-make-make install only perform step 1 and 2. To perform step 3 as well you have to call a special make target for this actually paranoidly step, but do not remember of hand which.
--
Karma 50, and all I got was this lousy T-Shirt.
no body
n/t
Just create a source tarball for each release and store it offsite. Then you can at any time check out the old sources from CVS and compare them with your tarball. Then you can compare the source tarball of this release with the one from the last one, ideally read that diff manually for bugs, and make a cvs diff, which you compare with the diff of the tarballs you made.
You can do that at any interval you choose.
Um, so, if CVS runs as user "cvs", which can write your source. Have fun to verify that nobody installed an exploit in your software
Yes, running as user prevents from the CVS binary itself being comprimised, which would allow same nasty tricks to hide exploits. But maybe you can achieve almost the same with smart, unusual rcs files.
But otherwise, your source is probably the most valueable asset on that machine (you're not running the company database on the same machine, are you?), so write access to the source *is* severe.
A "normal" build like the one you describe doesn't even do the compile twice. Only step #1 is done. (That's not what we call a normal build, so that's why I didn't mention it.)
You call the triple-stage idea "actually paranoidly," but I assure you that it's still needed when the native compiler/library is buggy or in some ways lacking. Most Linux users and distros use an earlier version of GCC as the "native compiler" in step #1, which makes steps 2 and 3 (usually) unnecessary. Perhaps that's why you think 2 and 3 are paranoid, but it's good to remember that GCC's target platform is far wider than Linux.
The fact that a simple "make"/"make all" does not do the 3-stage build performed by "make bootstrap" is considered a bug by some of the maintainers. We're actually trying, in the medium- and long-term, to have more of the compiler built in the 3-stage fashion, not less.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
The Fox project at CMU is studying the use of advanced programming languages, such as ML, for the construction of system software. They already have a web server written in ML.
Java isn't any less "free" than C even though it is a much more secure language.
Garbage collection is not secure. Safe pointers is not secure. Java is not secure. C is not secure. A language can be as insecure as the coder tells it to be. Nothing you want to believe will change this.
If you use a language with security features built in you spend less time auditing and more time being productive.
If you worked with me, you would be fired right now. This is the exact mentality that leads to security problems in the first place. "The language is secure so I don't need to audit"
No offense, but you really just destroyed your credibility with me by saying this, and I'm done talking to you.
Dacels Jewelers can't be trusted.
"The language is secure so I don't need to audit"
Who said that? Did I say that? No, I did not say that. I said you spend less time auditing. Please don't put words in my mouth. Since there are (for example) no double free errors in Java, you don't have to check for them. Therefore you spend less time auditing. You still have to audit for errors that still can occur in Java. Duh.
I'm done talking to you.
Classic "uh-oh, I'm losing the argument" cop-out. Oh well.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
Classic "uh-oh, I'm losing the argument" cop-out. Oh well.
No, it's the "I'm arguing with an idiot with no scope of reality" statement. I didn't say you said that verbatim, but what you did say was just as idiotic. You shouldn't spend less time auditing. You should not sacrifice security if the application should be secure (always). Any developer of mine that decides he doesn't need to audit, or spend less time than what should be applied, will find himself quickly unemployed.
Since there are (for example) no double free errors in Java, you don't have to check for them.
Pairing alloc/free's in properly designed code takes all of about a tenth of a second. Auditing code ensures good design, not syntactic checking. Good design will eliminate most of those problems.
It seems you don't know C well enough to know that at a quick glance you should be able to see any of the conventional mishap-bugs (double free, buffer overflows) relatively easy.
Dacels Jewelers can't be trusted.
But you're not sacrificing security. If you spend less time auditing code that has much fewer security holes, you get the same level of security in the end. You can never guarantee perfect security, only extremely good security. If the language gives you a head start, it takes less time to achieve the same level of security.
Pairing alloc/free's in properly designed code takes all of about a tenth of a second.
Oh, right. And next you'll tell me that loop constructs are for lazy programmers because constructing them with gotos only takes "about a tenth of a second". Give me a break. For one thing, it takes longer than that in any reasonably complex project. For another thing, humans will occasionally make a mistake. Poof, security hole. Compilers don't make those kind of mistakes. Why not let the compiler do it, both for coding speed and security reasons?
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
For another thing, humans will occasionally make a mistake. Poof, security hole. Compilers don't make those kind of mistakes. Why not let the compiler do it, both for coding speed and security reasons?
Which is why most security-based applications (aside from openSSH, which I wont get into) don't have many problems aside from implementation logic issues. If you design and code with security in mind, it's a moot point.
Dacels Jewelers can't be trusted.