Date: Mon, 23 Apr 90 02:50:43 PDT Subject: Security Digest V2 #12 Security Digest Volume 2 Issue 12 subject(s): SECURITY LIST CHANGES compress, crypt, and CBW-like codebusters Re: crypt(compress()) Re: Uutry in HDB The unix security mailing list is by invitation only and contains sensitive material which SHOULD NOT BE REVEALED to non-members. DO NOT PUT ANY LIST CONTENTS IN LOCATIONS ACCESSABLE TO NON-MEMBERS. If you must keep copies on-line, please encrypt them at the very least. PLEASE POST TO: security@uninet.cpd.com PLEASE SEND EMERGENCY ALERTS TO: security-emergency@uninet.cpd.com PLEASE SEND REQUESTS TO: security-request@uninet.cpd.com Postings that describe security holes/fixes have a * in their subject. ------------------------------------------------------------------------ [ To those of you that noticed some missing postings about the Yellow Pages bugs, they have been shuffled to the next digest, because I am in the process of restructuring the list. Read on ..... - neil ] Date: Sun, 22 Apr 90 23:31:33 PDT From: neil (Neil Gorsuch) Subject: SECURITY LIST CHANGES [ Following is a copy of a usenet posting that I just sent out to news.sysadmin and alt.security. I apologize for including most of it, but I feel that the members of the security list deserve as much information as possible about the upcoming changes to the security list, and this posting contains a lot of useful information. I will make further comments in []'s within it. Remember, the stuff outside of []'s is directed to the news.sysadmin lynch mob 8-). - neil ] Contrary to popular belief, I applaud the creation of alt.security and hope that it does well. I will be doing my part by posting quite a bit of stuff there. I am setting up a very paranoid 8-) internet gateway that I feel will be of interest, and will post a lot of methodology and even source code of modified network programs regarding that. Anyone that wants an nntp feed of alt.security, give me a call in a couple of weeks. If you want a uucp feed of alt.security and are willing to poll zardoz, call me now and I will add a number of uucp feeds of that group. If you want a mail feed of alt.security, I will even add a few of those, as long as you are an internet site, or are willing to poll zardoz. In fact, I might even be amenable to setting up a mail/news gateway for it, if someone tells me which software works well for that (email or phone the answer please, I don't read this news group very often). [ The almost 8-) full details of the internet gateway will of course be released to the security list first, so that anything that I miss can be found by the list members before I let the world know anything about my system's defenses - neil ] LIKE A LOT OF YOU, I AM EXTREMELY BUSY. DON'T TAKE A NON-REPLY AS ANYTHING BUT THAT. There have been some long delays in answering list membership requests, and I haven't gotten around to having the security-request alias send back an automatic acknowledgement of receipt. The former is being rectified by the changes revealed below, and the latter will be rectified at some point (sooner if someone sends me a nice awk script to find the best return address from a mail header 8-). [ Please send me any awk or perl scripts that you have - neil ] I do not believe in "security through obscurity" but prefer widely available security discussions regarding methods, tips, procedures, and other matters, as long as they don't touch on security holes that CAN'T BE FIXED BY BINARY LICENSE SITES. THERE IS NO NEED FOR THE WORLD AT LARGE TO KNOW ABOUT NEW SECURITY HOLES THAT BINARY SITES CAN'T FIX UNTIL THE VENDORS SUPPLY A FIX AND HAVE DISTRIBUTED IT FOR A REASONABLE AMOUNT OF TIME. The vendors ARE contacted by CERT and ARE probably on the security list. Please don't post newly found security holes to the world at large first. Send them to CERT (cert@cert.sei.cmu.edu) and to the security list (security@uninet.cpd.com) first. Relax 8-), they will still be disseminated to the world at large as explained below. You have to realize that some sites are at a much higher risk from crackers (casual or dedicated), and that the security list changes I am about to describe will still allow the world at large access to information regarding fixing security holes in a reasonable fashion. There has to be some compromise between the ideal world where all information is freely available to all, and a world where the law enforcement agencies and the dedicated crackers and the lawyers and their lawsuits dictate computer usage. Some people seem to have gotten the wrong impression of my goals for the security list. It originally was started as a discussion forum and early warning system for newly found security holes, including NON-FIXED ones. It has also become a relatively noise-free discussion forum for unix security matters. I am now changing the list somewhat to accomodate both goals, as follows: 1. The (bulk of) the security list will be much easier to join, and will continue to have the relatively noise-free discussions of security topics that it currently enjoys, as well as receiving delayed postings regarding new security holes that are fixable by binary license sites and more detailed information regarding the security holes than the world at large will receive. The typical member (and I will make reasonable exceptions) is a system administrator of an internet connected system or of a very large system. To join, email a request to security-request@uninet.cpd.com or to uunet!zardoz!uninet!security-request. The more information supplied, the better. You can even mention news.sysadmin, now that I have responded to my detractors 8-). [ The delay from hole knowlege to larger list posting will be 2 - 4 weeks, enough time for people to find fixes, but short enough that the larger list members will still get notification way ahead of everyone else. If you feel a different delay is appropriate, please tell me why by phone or email to "neil" - neil ] 2. A small portion of the security list will receive postings regarding UNFIXED security holes and very detailed COOKBOOK style instructions on utilizing security holes. These people will be the pool of people that help to solve the UNFIXED security holes, or that administer very large internet sites or other sites that are at a substantially increased risk. In fact, I will keep on tightening it until postings there do not leak quickly, if at all, to the "professional" hacker network. It will not be a closed list, contact me if you want on it, but you'd better be prepared to really justify your inclusion. It would be much better if you can get someone already on it (you'll have to find someone you know 8-) to recomend you. The "core" will participate in the same discussions that the bulk of the list will, the only difference will be in how NON-FIXED security holes and security hole COOKBOOKS are treated. [ I will announce the members in a few weeks (to the members only, I don't want anyone else to know which spool directories to try to get at). If you haven't received anything by then, please send mail to "neil", NOT 8-) security-request explaining why you should be on the smaller list. A lot of people that I know personally are already slated to be on it. I will almost certainly use CERT as a filter/reference also (I'll call you guys tomorrow). - neil ] I will probably (I may check with my lawyers first before making the final decision on this policy) post the details for FIXING new security holes to alt.security, with a delay from the time that they appear in the larger security list. I will certainly post some of the security tips and methods discussed on the larger security list to alt.security. [ I don't believe in letting lawyers help me make decisions until I'm actually in a lawsuit 8-). I am thinking of a 3 week delay here. Anyone who is uncomfortable with this whole idea, please contact me. I will of course honor any requests by finders of holes to not spread them outside of the core list. - neil ] In article <544@compnect.UUCP> dave@compnect.UUCP (Dave Ratcliffe) writes: >In article <11137@hoptoad.uucp>, gnu@hoptoad.uucp (John Gilmore) writes: >> Someone >> masquerading as "root@feodor.UUCP" forged an rmgroup with Subject: >> "you've got to be kidding", Message-ID: , and no other >> identifying information. >Possibly the person who origonated that message is afraid that >alt.security will enable administrators to swap info that will keep him >from playing his little games. If so, more power to it. [ I hope that nobody on this list thought for a second that that was me, and that nobody on this list was the person that pulled that stunt. If anyone knows who did it, please tell me. You can't stop popular movements like alt.security even if you try, and I quite frankly don't want to see it stopped anyway, it will do much more good than harm (I hope 8-). - neil ] ------------------------------------------------------------------------ Date: Sat, 14 Apr 90 04:24:11 PDT From: uunet!paralogics!shaw (Guy Shaw) Subject: compress, crypt, and CBW-like codebusters In Volume 2, issue 11, two people pointed out an unfortunate error in my posting about crypt and compress: I think what was being suggested was crypt(compress()) not compress(crypt()). I *hate* it when I do that. I'm sorry. I did originally understand Mr. Mueller to be talking about crypt(compress()), and I wanted to point out that a fixed magic number is even easier to look for than statistical profiles. Charles Green overlooked my blunder (thank you) and addressed my concern. A prior compression can be used if size of the result is important; if the compression technique involves a fixed header (such as compress(1), this could even be stripped off before sending and replaced at the destination to reduce the amount of known data in the text. Ok, so you can make it a little harder. The first 2 bytes are the magic number, the 3rd byte is number of bits and block-compress flag; they can be stripped off. Here is a sample of the first 16 bytes of 12 compressed, saved USENET news articles (comp/lang/c for 1989, one month each): 1F9D9046 E4BC6903 228C1C81 6D808481 1F9D9046 E4BC6903 A2CD9B3A 73CA0069 1F9D9046 E4BC6903 428D9839 40CC9471 1F9D9046 E4BC6903 A24E1D37 65E88408 1F9D9046 E4BC6903 A24E1D37 65E88418 1F9D9046 E4BC6903 A24E1D37 65E884A0 1F9D9046 E4BC6903 A24E1D37 65E884A8 1F9D9046 E4BC6903 A24E1D37 65E88468 1F9D9046 E4BC6903 A24E1D37 65E88418 1F9D9046 E4BC6903 A24E1D37 65E88468 1F9D9046 E4BC6903 A24E1D37 65E88418 1F9D9046 E4BC6903 A24E1D37 65E884B8 The first 8 bytes are identical, and 9 out of 12 of these files are the same for the first 15 characters. This isn't an artificial example; I really did pick this off the top of my head. I am cheating, in a way, though, because all these files start with 'From '. Security digest, as it is sent now, is a lot worse; they are all the same in the fist 32 characters, and most are the same in the first 36 characters, because the all come from the same place. Ok. I'm still cheating by taking advantage of the fact that these files start with common information. But, in the real world, there is a lot of that going on, especially in published digests with the same announcement string up front, issue after issue. Let's make it harder. Send your "secure" (ha!) messages with a line of about 50 characters of random junk in front. Now, we are getting to the fun stuff. My SOID[1] still acts up when I contemplate using this scheme. Not just any bit patterns constitute a valid compressed file. I haven't done measurements, but I think it would not be too expensive, by cryptanalytic standards, to run trial decompress on the first n characters of a candidate, just too see if it blows up. A file constructed from the 3 bytes of magic followed by random bits ought to make decompress die quickly (i.e. cheaply). I think that if this were adopted as a common method for "secure" communication, it would lull some people into a false sense of security. The way I look at it, the burden of proof rests with anyone who would propose that this is secure, and I do not have to prove that it is insecure. Although I have shown, casually, by counter-example that you can't just use crypt(compress()) naively, because we are creatures of regular habits. And, I didn't even have to try hard. Compress was not designed with security in mind. Someone can probably show that, with the proper precautions, crypt(compress()) makes life harder for crackers. But, this is still just a palliative. In the long run, if this method comes into widespread use, *and* has some measure of success, it will delay the widespread use of stronger encryption methods - and that's the best case scenario. Use stronger encryption methods. Accept no substitutes (or transpositions :-). [1] SOID: Originally, "Sense Of Impending Doom", in this case, "Sense Of Impending Decryption" ------------------------------------------------------------------------ Date: 18-Apr-90 23:37:17 CST (Wed) From: uunet!letni.lonestar.org!doug (Doug Davis letni.lonestar.org) Subject: Re: crypt(compress()) Basicly if you just crypt a compressed file you are not providing much security, the person breaking in is now sure of the first 5 "positions" of your rotor. This is because of compresses magic numbers, bit sizes, etc. Knowing that I *absolutely* know some of the positions the next set could be figured out by study of how the compression algorithm works. The last time I did this (about three years or so ago) it took about a day to crack a ~30k compressed file using cbw, calculator, and lots of scratch paper. Someone also asked if the string of dashes in the security digest would make it easier to crack it if it was crypted, absolutely, any reoccuring string of bytes will weaken the structure. Also if I was presently engaged in "trapping" issues of the digest from someones account and they started showing up crypted. I could generate a very good keyword list from the stolen back issues. Chances are I could get the HEADERS in no time. The rest would become trivial in very short order. ------------------------------------------------------------------------ Date: Sat, 14 Apr 90 13:58:50 -0400 From: uunet!att!erebus!wcs Subject: Re: Uutry in HDB In Digest 2.11, Bud Hovell writes > [HDB replaces passwd with ???] It may be worth noting that this is only true if the originator is *not* 'root' (if our local system is typical). We altered our Uutry script to create an output /tmp file readable *only* by the login user who runs it. Be careful doing this - you may break Uutry for users! What happens is that one user runs "Uutry foovax", leaving the file /tmp/foovax mode 600. Another user also wants to run "Uutry foovax", but can't because /tmp/foovax is unreadable/unwriteable. Before we got System V R3.* sticky directories, the second user could at least rm /tmp/foovax, but now that's impossible because it's owned by the first user. So if you do a modification like this, make sure you use a uniquely-named tmpfile, such as /tmp/foovax.$$ ------------------------------------------------------------------------ End of Security Digest Volume 2 Issue 12 **********************