[Fwd: iXsecurity.20020327.tivoli_tsm_dsmcad.a]
Just in case somebody out there is not subscribed to BUGTRAQ :) -- Kyle Sparger "Dangerous to us all are devices of an art deeper than our own." --- Begin Message --- iXsecurity Security Vulnerability Report No: iXsecurity.20020327.tivoli_tsm_dsmcad.a === Vulnerability Summary - Problem:The Tivoli Storage Manager webserver, running on port 1581 has a buffer overflow condition. Threat: An attacker could make the webserver crash and possibly execute arbitrary code. Affected Software: Tivoli Storage Manager version 4.2.x.x. Platform: Windows NT4/2000. Vulnerability Description - A request for the URL A.Aapproximately_1292_more_A's to the webserver running on port 1581 (TSM Client Acceptor) will result in a crash, overwriting EIP. The buffer overwriting EIP is in a widestring format, making it a little more difficult, although not impossible, to exploit. Solution See APAR IC33211 Apply Patch V4.2.1.32 currently available at http://www.tivoli.com/support/storage_mgr/clients.html For additional information or assistance please contact your IBM Service Representative at 1-800-IBM-SERV Additional Information -- Tivoli was contacted 20020327. This vulnerability was found and researched by Patrik Karlsson & Jonas Ldndin [EMAIL PROTECTED] [EMAIL PROTECTED] This document is also available at: http://www.cqure.net/advisories/ --- End Message ---
Re: don´t aynone know anything about Encryption in TSM.
> (unless they can hack it, but then any encryption scheme is subject to > hacking). And this is a very important point. I could be wrong, but I seem to recall that TSM's encryption uses straight up DES, which uses a 56 bit key. It has been proven that very determined people can brute force 56 bit DES -- distributed.net, which utilizes idle time of thousands of computers, was able to do it in less than 24 hours. There are design specs available for theoretical computers which are supposed to be able to brute force 56 bit DES within minutes -- but the cost of these computers is generally considered prohibitively expensive. However: 1. Consider the following -- KaZaa, a fairly popular napster-alike, has been piggybacking programs for awhile now, one of which is designed to allow remote users to utilize idle cycles on the computers it's installed on. KaZaa is used by thousands of users. Also, how many thousands of computers out there have been broken into, or are waiting to be broken into? All of these are sources of computing power that could be used to crack DES keys. 2. 'Prohibitively expensive' is relative. I've heard estimates that put the price of building such a computer at a little over $1B USD. But then, consider how many billions of dollars countries have spent launching spy sattelites -- don't you think that they would spend just one more billion to be able to actually _use_ the encrypted information they intercepted? :) And if Moore's Law holds true, I seem to recall estimates that place 56-bit key cracking in under a week at 2020-2030. Will your data still need to be secret then? :) Basically, what I'm saying is, TSM's encryption is better than nothing, and is suitable for many purposes, but your original statement, "They have extremly valible data witch may not get in the wrong hands." ... that indicates that this may not be suitable for your case :) If you _really_ need to make sure people can't get it, you need to use a lot more than 56 bits. 128 is the bare minimum these days, and even that is starting to come under fire :) -- Kyle Sparger
Re: Point in Time Backups
This may be totally unsuitable for your environment, but actually, I had been thinking about the properties of 'REUSEDELAY' and database backups recently, and I think maybe it could be used to create something to this effect for your customers at large; I wouldn't know how to drill it down to individual nodes, however. Also, because of the way it works, it would only really be useful for archival purposes, not for data you anticipate needing to restore on a regular basis. The actual restore would be a severe pain :) The idea goes something like this: 1. Assume you have the following pools -- DISKDATA, TAPEDATA, and COPYTAPE. 2. DISKDATA is obviously a disk pool, TAPEDATA is your primary tape media, and COPYTAPE is your backup storage pool for both DISKDATA and COPYTAPE. 3. Define a third storage pool, COPYPIT -- copy-point-in-time. Do your normal client backup/migration/stgpool backup with DISKDATA, TAPEDATA, COPYTAPE. Whenever you want to do a point in time backup, do _another_ backup of DISKDATA and TAPEDATA onto COPYPIT. Take a database snapshot. Send COPYPIT and the DBSNAPSHOT offsite, and leave them offsite forever (or out of library). Take note of which volumes and database snapshots correspond to which dates -- you might want to store these offsite too. In the future, if you need to restore from one of the point in time backups, recall the tapes and the snapshot you took from the appropriate day, and you should be able to restore to that point in time. Drawbacks: 1. You have to be very, VERY careful about reclamation. The TSM server is going to be expiring these files, and you'll likely have no real way of knowing which volumes to reclaim. More than likely, your best, safest bet is to write off the tapes, and never reclaim them. 2. Restoration is a HUGE, MASSIVE pain. You'll need to recall the tapes, restore the database, then restore the storage pool, etc, before you can even think about restoring the data. This is certainly no help if you need to be able to restore from these PIT backups on a moments notice. You'll also need lots of scratch tapes to do the restoration, and you'll have to take precautions to make sure that you don't accidentally restore over current data -- probably by removing all 'current' tapes from the library, or using a totally different machine and compatible library. 3. I don't think you can easily do this only for a subset of nodes. Advantages: 1. Easier to maintain than doing more than a certain amount of backupsets. Comments? I may need to do something like this in the future, and if anyone has any reasons why this is not really workable, it'd save me a headache having to find it out the hard way. And yes, I know this is a horrible kludge. :) Thanks, Kyle Sparger
Re: Idea for a TSM feature
Right now, AFAIK, there's no way to influence how Tivoli makes decisions about which files to remove from the migrated file cache -- I think adding ways to influence those decisions would probably be better than to add a 'special' disk storage pool type. The ability to say "Okay, if there's a shortage of space in the cached disk storage pool, prefer to keep files associated with management class A in the cache over files associated with class Y. Class Z should remain cached no matter what -- if that means run out of space, then run out of space." That would be much slicker, and provide more management options than just adding a whole different storage pool type :) It would also be neat to be able to copy files that have been removed from the cache back into the cache from the tape storage pools. Ah, the beauty of storage management. Kyle Sparger
Tape Copy pools and Colocation
Hello, I'm starting to implement tape copy pools. My primary pool has colocation enabled, in order to speed up restores. My primary storage pool currently is using 27 tapes at varying degrees of usage. When I did a test BACKUP STGPOOL, the output indicated that it wanted to use another 27 tapes, even though that would end up leaving unused space on each tape. I expect that the copy pool will not be used a whole lot; I intend to move these tapes out of the library after each backup, and as such, prefer density and tape efficiency to speed of recovery from these tapes. I was wondering if there is a way to have it use the copy pool such that it uses the fewest tapes possible, filling up each tape fully before pulling another one from scratch. Or, does it do this already, and is the test run just being ultra-conservative? Thanks, Kyle Sparger - System Administrator [EMAIL PROTECTED] - http://www.dialtone.com Voice - (954) 581-0097 x 122 Why do programmers get Halloween and Christmas mixed up? OCT(31)=DEC(25)
Re: volume status being changed erroneously
> So we can dismiss a error at the factory. I wouldn't necessarily say so. We recently purchased a 3583 library and 40 LTO tapes -- within the last 6 months or so. My tape drives rejected three of them with error #6 (bad media). So, I RMA'd them, and got three replacements sent to me. Of those three, two were also rejected by the drive. So, I RMA'd those -- my embarrased tape provider sent me 10. Of those, 2 were also rejected. So, out of a grand total of 53 tapes, 7 of them were bad; 13.2% of the total amount. That's a pretty high failure rate. Now, your symptoms are a little different, but considering that I had three separate tape deliveries, and there were a signifigant amount of bad ones in each delivery, I wouldn't consider 30% of your LTO library's tapes being bad to be beyond reason. This is new technology. I'll bet they're still ironing out some stuff ;) Thanks, Kyle Sparger
