December 2003 - Legacy - lists.gtalug.org

video plugin for mozilla on linux
by joehill-rieW9WUcm8FFJ04o6PK0Fg＠public.gmane.org 03 Dec '03

03 Dec '03

On Wed, 3 Dec 2003 14:10:47 -0500 Austin <aacton-B71PBEe7S7Y at public.gmane.org> wrote: > > I want to install real player and flash plug-ins on Mandrake 9.2. > > First I am trying to get flash to work, but after installation I > > receive: > > > > LoadPlugin: failed to initialize shared library > > /usr/lib/mozilla-1.5/plugins/libflashplayer.so > > [libstdc++-libc6.2-2.so.3: cannot open shared object file: No such > > file or directory] > > # urpmi libstdc++2.10 > > BTW, the rpm is non-free software so it's only available on the > PowerPack CD's and on the club website. Strange, this wasn't the case on 9.1. I had Texstar's Mozilla Flash plugin workin' fine, and I certainly have no club membership...yet ;-) Now I'm stuck in the same situation as Lloyd. -- JoeHill ++ ICQ # 280779813 Registered Linux user #282046 Homepage: www.orderinchaos.org +++++++++++++++++++++++++++ "The US is our trading partner, our neighbour, our ally and our friend... and sometimes we'd like to give them such a smack!"-- Rick Mercer -- The Toronto Linux Users Group. Meetings: http://tlug.ss.org TLUG requests: Linux topics, No HTML, wrap text below 80 columns How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml

1 0

Debian attacker may have used new exploit
by jmm-TU2q2He6PgRlD5gtYiU6kEEOCMrvLtNR＠public.gmane.org 03 Dec '03

03 Dec '03

On Wed, Dec 03, 2003 at 03:23:44PM -0500, JoeHill wrote: > On Wed, 3 Dec 2003 15:23:31 -0500 > John Macdonald <jmm-TU2q2He6PgRlD5gtYiU6kEEOCMrvLtNR at public.gmane.org> wrote: > > > Nope, we cannot stop them. But delayed disclosure > > will, in at least some cases, reduce the number of > > malicious users with such knowledge before a fix > > is available. > > In both of your posts, you start from the assumption that immediate public > disclosure contributes nothing, but that's all it is, an assumption. I am > positing that putting any limits on the free exchange of this information is > inherantly worse than any *potential* harm (never once demonstrated, only > theorized) done by such disclosure. Straw men, babies, and bathwater, are all > cute, but I have yet to see a strong argument, with evidence, that the free > exchange of all security-related information, an important part of not only > awareness and education, but also development of new tools to combat > vulnerabilities (or the proper eradication of software which is unfixable, ie. > Internet Exploder), somehow does more harm than good. If both sides of an argument take the approach that "if it is not proven otherwise, my belief should prevail" then you never come to a useful resolution. Far from proving that immediate disclosure has an advantage over delayed disclosure, you haven't even suggested any way in which it *might* have an advantage. All of your arguments apply only to the comparison against non-disclosure; which no-one is trying to claim as a good practice. That is a straw man - you put a false argument into the mouths of your opponent so that you can knock it down. It does not accomplish any useful progress in the discussion. It is quite obvious that immediate disclosure will sometimes (not always but sometimes) cause damage that delayed disclosure would ameliorate. This will happen when: - no cracker happened to already know about the particular hole being disclosed - only one cracker already knew about the hole, but he was saving it to use for a particular attack - every cracker that knew about this hole had other things to do and wasn't developing an exploit yet, but the disclosure made the potential damage time limited and so it was worth switching to exploiting this hole at this time instead of other work Try and prove that none of these could ever happen! (But don't just prove that they will sometimes not happen - I already admit that, but that is irrelevant. You are arguing that immediate disclosure should be done for every case.) -- The Toronto Linux Users Group. Meetings: http://tlug.ss.org TLUG requests: Linux topics, No HTML, wrap text below 80 columns How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml

1 0

Debian attacker may have used new exploit
by joehill-rieW9WUcm8FFJ04o6PK0Fg＠public.gmane.org 03 Dec '03

03 Dec '03

On Wed, 3 Dec 2003 17:35:15 -0500 John Macdonald <jmm-TU2q2He6PgRlD5gtYiU6kEEOCMrvLtNR at public.gmane.org> wrote: > Far from proving that immediate disclosure has an > advantage over delayed disclosure, you haven't > even suggested any way in which it *might* have > an advantage. Read my post again, and the link to the Security Focus article, you will find I have in fact done so, only you have chosen to ignore it. > All of your arguments apply only to the comparison > against non-disclosure; which no-one is trying to > claim as a good practice. That is a straw man - > you put a false argument into the mouths of your > opponent so that you can knock it down. It does not > accomplish any useful progress in the discussion. I nowhere engaged in such a practice, I argued against *any* limits being placed on the free exchange of information, for reasons I have already stated, and have provided references for. Not once did I claim or assume that the "other side" of the argument was no disclosure at all. As Robert suggested would happen, this *is* getting repetitive, and now you are accusing me of something you seem to be doing yourself. So, to end the thread, placing limits on the free exchange of any information, whether it is for some limited time or perceived good, is the kind of slippery slope that leads to a regime **Hitler** would have loved ;-) -- JoeHill ++ ICQ # 280779813 Registered Linux user #282046 Homepage: www.orderinchaos.org +++++++++++++++++++++++++++ "You tell me it's the institution; Well you know, you better free your mind instead..."-- John Lennon -- The Toronto Linux Users Group. Meetings: http://tlug.ss.org TLUG requests: Linux topics, No HTML, wrap text below 80 columns How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml

1 0

Smoothwall and running a server via a IPMASQ address
by wmcgilvery-6d3DWWOeJtE＠public.gmane.org 03 Dec '03

03 Dec '03

Please clarify your setup. Regards, Wil McGilvery Manager Lynch Digital Media Inc 416-744-7949 416-716-3964 (cell) 1-866-314-4678 416-744-0406? FAX www.LynchDigital.com -----Original Message----- From: Teddy Mills [mailto:teddymills-VFlxZYho3OA at public.gmane.org] Sent: Wednesday, December 03, 2003 3:55 PM To: tlug-lxSQFCZeNF4 at public.gmane.org Subject: [TLUG]: Smoothwall and running a server via a IPMASQ address Im going to try using a Smoothwall lbox as my firewall. Well I figure this is a more proper way of doing things, since iptables/firewall should be on a seperate box. My only thoughs are before I begin are: I only have 1 STATIC IP. Therefore the SmoothWall will use the Static IP. The server and its 1000 and 1 settings currently set for the STATIC interface, and all server services will have to be set to work through eth1 192.168.1.2 on my server. So all services will have to be forward and work through that 192.168.1.2 address. Most services 8,22,25,53,80,110,113,143 work through eth1 currently. Running a server via a IPMASQ address, Im sure is done all the time, but its giving me second thoughs on the SmoothWall install. This could get ugly. I could paint myself into a corner far worse just having iptables not working. --------------------------------------------------------------- teddy mills http://www.vger.ca VGER directives...To collect...all that is collectable. To sell...all that is saleable.To merchandise...all that is merchandisable. Family Guys, Quagmire "allllllllllllllllllllllllllllllll right" -- The Toronto Linux Users Group. Meetings: http://tlug.ss.org TLUG requests: Linux topics, No HTML, wrap text below 80 columns How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml -- The Toronto Linux Users Group. Meetings: http://tlug.ss.org TLUG requests: Linux topics, No HTML, wrap text below 80 columns How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml

1 0

Smoothwall and running a server via a IPMASQ address
by teddymills-VFlxZYho3OA＠public.gmane.org 03 Dec '03

03 Dec '03

Im going to try using a Smoothwall lbox as my firewall. Well I figure this is a more proper way of doing things, since iptables/firewall should be on a seperate box. My only thoughs are before I begin are: I only have 1 STATIC IP. Therefore the SmoothWall will use the Static IP. The server and its 1000 and 1 settings currently set for the STATIC interface, and all server services will have to be set to work through eth1 192.168.1.2 on my server. So all services will have to be forward and work through that 192.168.1.2 address. Most services 8,22,25,53,80,110,113,143 work through eth1 currently. Running a server via a IPMASQ address, Im sure is done all the time, but its giving me second thoughs on the SmoothWall install. This could get ugly. I could paint myself into a corner far worse just having iptables not working. --------------------------------------------------------------- teddy mills http://www.vger.ca VGER directives...To collect...all that is collectable. To sell...all that is saleable.To merchandise...all that is merchandisable. Family Guys, Quagmire "allllllllllllllllllllllllllllllll right" -- The Toronto Linux Users Group. Meetings: http://tlug.ss.org TLUG requests: Linux topics, No HTML, wrap text below 80 columns How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml

1 0

Encrypted filesystems?
by plp-ysDPMY98cNQDDBjDh4tngg＠public.gmane.org 03 Dec '03

03 Dec '03

On Tue, 2 Dec 2003, cbbrowne-HInyCGIudOg at public.gmane.org wrote: > I use CFS, which is fairly widely available in packaged form, which > "plays" as an NFS server. It's a bit slow, but it is pretty portable, > requiring no kernel mods, which strikes me as a win. What happened with rubberhose ? Peter -- The Toronto Linux Users Group. Meetings: http://tlug.ss.org TLUG requests: Linux topics, No HTML, wrap text below 80 columns How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml

1 0

Debian attacker may have used new exploit
by joehill-rieW9WUcm8FFJ04o6PK0Fg＠public.gmane.org 03 Dec '03

03 Dec '03

On Wed, 3 Dec 2003 15:23:31 -0500 John Macdonald <jmm-TU2q2He6PgRlD5gtYiU6kEEOCMrvLtNR at public.gmane.org> wrote: > Nope, we cannot stop them. But delayed disclosure > will, in at least some cases, reduce the number of > malicious users with such knowledge before a fix > is available. In both of your posts, you start from the assumption that immediate public disclosure contributes nothing, but that's all it is, an assumption. I am positing that putting any limits on the free exchange of this information is inherantly worse than any *potential* harm (never once demonstrated, only theorized) done by such disclosure. Straw men, babies, and bathwater, are all cute, but I have yet to see a strong argument, with evidence, that the free exchange of all security-related information, an important part of not only awareness and education, but also development of new tools to combat vulnerabilities (or the proper eradication of software which is unfixable, ie. Internet Exploder), somehow does more harm than good. There isn't even any evidence that having one "script-kiddie" releasing a worm or virus into the wild is somehow a better or less damaging situation than having two, or five. The point is there are *enough* that one or two more are not going to make one whit of difference. Constraining information, therefore, has no purpose, at least that can be quantified, whereas the uninhibited dialogue on security has enormous positive benefits. The current "regime", as it were, is not working. The internet is gradually sliding away from us into a spam and virus-ridden pit, and it is precisely because certain proprietary software vendors have been allowed to hide their flawed approach to software design, and blame everything on script-kiddies and other malcontents. Instead, we should be exposing these flaws as they become apparent, and if it means that "risk reduction" means using, say, Mozilla, instead of an inferior and insecure product like Internet Explorer, so be it. Extrapolate that analogy as you see fit ;-) -- JoeHill ++ ICQ # 280779813 Registered Linux user #282046 Homepage: www.orderinchaos.org +++++++++++++++++++++++++++ He who controls others may be powerful, but he who has mastered himself is mightier still.-- Lao Tsu -- The Toronto Linux Users Group. Meetings: http://tlug.ss.org TLUG requests: Linux topics, No HTML, wrap text below 80 columns How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml

1 0

Debian attacker may have used new exploit
by jmm-TU2q2He6PgRlD5gtYiU6kEEOCMrvLtNR＠public.gmane.org 03 Dec '03

03 Dec '03

On Wed, Dec 03, 2003 at 11:02:47AM -0500, JoeHill wrote: > On Wed, 3 Dec 2003 09:59:43 -0500 (EST) > Robert Brockway <robert-5LEc/6Zm6xCUd8a0hrldnti2O/JbrIOy at public.gmane.org> wrote: > > > Software vulnerabilities are normally fixed by patches but I'll agree that > > security overall is more a function of awareness. I think this sentence > > mixes up too different concepts (specific security issues vs security > > procedures and knowledge). > > Not at all. You are again assuming that "script-kiddies" gain somehow from the > widespread "awareness" of vulnerabilities, an assumption to which I do not > subscribe, mainly for lack of evidence. Straw man. It doesn't matter whether script-kiddies learn about a hole, but whether they are fed with new exploit scripts. The exploit writers are the ones to worry about. If you can prove that exploit writers always know of vulnerabilities before any public disclosure; or else they always ignore any vulnerability that they learn of from a public disclosure, then you can argue that disclosure has not hurt. I think that you could not possibly prove those assertions, which means that you have to acknowledge that disclosure might possibly cause damage. > >From Security Focus: > > "A successful attacker requires three things: the opportunity to launch an > attack, the capacity to successfully execute the attack, and the motivation to > attack. An opportunity to launch an attack requires a vulnerable system and an > access path to the system. The capability to successfully execute the attack > requires knowledge of the vulnerability and the tools to exploit it. > > Proponents of the information dictatorship argument are targeting the second > requirement of a successful attacker: his capability to launch an attack. This > approach to the problem of computer security is flawed, and can only fail. You seem to think that there are only two choices: immediate public disclosure or long term secrecy. You give arguments that the first might not cause problems and that the second is bad. The middle ground; public disclosure after either a fix is available or significant time has elapsed; is not disproved by the "long term secrecy is bad" argument because it is not requiring or depending upon long term secrecy. It is not disproved by "immediate disclosure might not be bad" argument because immediate disclosure is not even going to be better and might be worse. > First, we cannot stop some small number of malicious users from gaining > knowledge of vulnerabilities, or access to the tools that exploit them. > Vulnerability information and exploits have legitimate uses with the computer > security field. They are part of research, are required in penetration testing, > and used by system administrator to test their systems, mitigate the risks by > gaining an in-depth understanding of the problem, and to verify that vendor > fixes work as advertised." Nope, we cannot stop them. But delayed disclosure will, in at least some cases, reduce the number of malicious users with such knowledge before a fix is available. -- The Toronto Linux Users Group. Meetings: http://tlug.ss.org TLUG requests: Linux topics, No HTML, wrap text below 80 columns How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml

1 0

Debian attacker may have used new exploit
by jmm-TU2q2He6PgRlD5gtYiU6kEEOCMrvLtNR＠public.gmane.org 03 Dec '03

03 Dec '03

On Wed, Dec 03, 2003 at 08:59:17AM -0500, JoeHill wrote: > On Wed, 3 Dec 2003 09:16:11 -0500 > John Macdonald <jmm-TU2q2He6PgRlD5gtYiU6kEEOCMrvLtNR at public.gmane.org> wrote: > > > Immediate public disclosure does not provide more eyes > > for a bug in MS code, just more eyes in the cracker > > community. > > That is a myth, propagated by MS and other proprietary vendors, to avoid > embarassment and having to do actual work to improve security. Immediate public disclosure of an MS bug provides zero additional eyes for fixing it. Guaranteed. Possibly, it might provide zero additional cracker eyes, but perhaps it might not. The best possibility there is for immediate disclosure to break even, more likely it loses. Let's toss coins for a while - heads you pay me $50, tails we call it a draw. Hey, you might not lose. > Witness the recent case of Diebold and their voting machines. If it were not for > the work of students and activists at Swarthmore College, no one would ever have > known of the security flaws. Diebold certainly showed no interest in fixing the > problem, even though internal memos showed they were aware of those flaws. It > was only after said students published the internal memos online that enough > pressure is being brought to bear on Diebold to fix the vulnerabilities. Now > what software were those machines running agian...? Oh, that's right, MS. That's not affected by this argument. Delayed public disclosure, to give them a chance to fix the problem, followed by automatic public disclosure a suitable time afterward will show up the cases that are showing no interest. In fact, it makes it far more obvious - they had a chance to fix the problem and just ignored it hoping no-one would ever notice. Immediate public disclosure denies them any opportunity to show the proper level of concern. > > Telling MS of a bug, and then telling the world later > > of the bug (and that MS was told a month earlier > > so that people can judge whether their response was > > adequate) provide more than ample pressure, and may > > reduce the number of exploits carried out against > > victims who have never had any warning or chance to > > apply a fix because there wasn't one. If MS responds > > prompty (which they are doing better at these days - > > they've learned that they have to), then when the > > public announcement goes out any attacks prompted by > > the announcement can only be applied against people > > who have not yet applied the fix. > > Again, facts and reality fly in the face of this argument. Hackers are usually, > if not always, aware of these vulnerabilities before the security > "establishment", and certainly before software designers can come up with a > patch. Full public disclosure is one way to give the vast majority of users a > head start, before a patch can even be issued, so that they can at least be > aware of the risk. In fact, following this logic, it could be proposed that > disclosure be even *more* widespread, as soon and as widely as possible. > Security issues are not solved by a patch, they are mitigated by awareness. Some crackers might already know of the problem, but that is not affected by either choice (delay or immediate publication). The issue is whether disclosure will cause any more crackers to learn of (it's not likely to make any of the ones that already know of it to forget, so we're back to at best breaking even and anything other than the best possibility is losing). > Finally, there is no way to develop an enforceable "policy" in this regard, so > it is not realistic to expect that, even if you assume this "myth" is true, > people will not go on publicly releasing info on exploits. It's more realistic > to find a way to deal with the *expectation* that the exploits are already > widely known, and to work from there. You're choosing between throwing out the baby with the bathwater or never bathing the baby. Automatic public disclosure is a good thing. Immediate public disclosure before a fix is available is sometimes no worse than delayed but could easily be worse. It is never better. > If you read the full account of the Debian incident, you will see that that is > exactly what happened, and exactly the attitude that was taken. Nothing radical > here! In fact, if you do a quick google on this topic, you will find that > nothing I'm saying is particularly original, this is the opinion of much bigger > fish than you or I. I read it. It appeared after they had a fix for the kernel and even so, it does not provide specific details of the mechanism used, not the binary of the program used. That is in no way "public disclosure in advance of informing the affected parties". It fits my model of appropriate behaviour perfectly well and provides no reason to choose your model instead. -- The Toronto Linux Users Group. Meetings: http://tlug.ss.org TLUG requests: Linux topics, No HTML, wrap text below 80 columns How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml

1 0

video plugin for mozilla on linux
by lloyd-fEEwcc3XMu8jODpR/OX0VQ＠public.gmane.org 03 Dec '03

03 Dec '03

On Wed, 2003-12-03 at 14:10, Austin wrote: > On 12/03/2003 01:04:38 PM, Lloyd D Budd wrote: > > I want to install real player and flash plug-ins on Mandrake 9.2. > > First I am trying to get flash to work, but after installation I > > receive: > > > > LoadPlugin: failed to initialize shared library > > /usr/lib/mozilla-1.5/plugins/libflashplayer.so > > [libstdc++-libc6.2-2.so.3: cannot open shared object file: No such > > file or directory] > > # urpmi libstdc++2.10 > > BTW, the rpm is non-free software so it's only available on the > PowerPack CD's and on the club website. Thanks! http://mandrake.redbox.cz/Mandrake/9.2/i586/Mandrake/RPMS/libstdc++2.10-2.9… I was in disbelief based on the version # of the RPM: libstdc++5-3.3.1-2mdk vs libstdc++2.10-2.96-0.83mdk -- The Toronto Linux Users Group. Meetings: http://tlug.ss.org TLUG requests: Linux topics, No HTML, wrap text below 80 columns How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml

1 0