- Legacy - lists.gtalug.org

C considered harmful: was Debian attacker may have used new exploit
by phiscock-g851W1bGYuGnS0EtXVNi6w＠public.gmane.org 04 Dec '03

04 Dec '03

Marcus - Thanks for the references. I may be incorrect, but I believe Heather Hinton was involved with the 'stackguard' project. She's now with IBM it Austin, Texas. Peter On Wed, Dec 03, 2003 at 11:36:04PM -0500, Marcus Brubaker wrote: > On Wed, 2003-12-03 at 22:55, Peter Hiscocks wrote: > > OK, I hate to flog a dead horse but really: > > > > Hmmmm, this is likely to start a looooong drawn out flame thread. > Language arguments almost always do. So, with trying to prevent that in > mind, I will avoid standing up for my general language of choice and > instead offer an alternative. > > > This exploit, like others against Unix machines many years ago, was based on > > a buffer overflow dumping the user into supervisor space. This, in turn, is > > a direct result of the fact that the C programming language does not check > > or enforce limits on a string length or buffer size - that's left up to the > > individual programmer. > > > > Surely, given the importance of security, it should be possible to fix the C > > language (or my preference, use a different one) to do systems programming. > > After all, C is not so much a systems programming language as a high-level > > version of assembly language. > > > > "Fixing" C in the sense you're imagining will never happen and people > often do use other languages for specific tasks. However, other > languages are not immune to buffer overflows as most of them are > actually written in C themselves. > > The better solution is things like stackguard[1] and execshield[2] which > actually fix the root problem: the stack should NOT be executable and > neither should most of the heap and likewise portions of memory which > are actively executable shouldn't be writable from userspace. > > > (Incidentally, a former profs at Ryerson, Heather Hinton, was working on > > such a mechanism to prevent stack overflows. I guess it's never been widely > > adopted.) > > Hinton...any relation to Geoffrey Hinton? At any rate, many people have > (and continue) to work on stack guards and similar solutions. See [1] > and [2]. As with all security measures, its just a question of getting > people to use them. > > -- > Marcus Brubaker <marcus.brubaker-H217xnMUJC0sA/PxXw9srA at public.gmane.org> > > [1] http://www.immunix.org/stackguard.html > [2] http://seclists.org/lists/linux-kernel/2003/May/0371.html and http://people.redhat.com/mingo/exec-shield/ > > -- > 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 -- Peter D. Hiscocks Department of Electrical and Computer Engineering Ryerson University, 350 Victoria Street, Toronto, Ontario, M5B 2K3, Canada Phone: (416) 979-5000 Ext 6109 Fax: (416) 979-5280 Email: phiscock-g851W1bGYuGnS0EtXVNi6w at public.gmane.org URL: http://www.ee.ryerson.ca/~phiscock -- 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

C considered harmful
by phiscock-g851W1bGYuGnS0EtXVNi6w＠public.gmane.org 04 Dec '03

04 Dec '03

OK, you have an excellent point, Henry, that people have chosen C for good reasons. I actually was on the receiving end of this kind of academic scorn at one point. I had developed a computer controlled sound system for use in the theatre, and this being 1982 or so, I had to use what was available, the Commodore PET. The system was written in a combination of Commodore Basic and 6502 assembly language. I was at a party of comp sci academics and one of the profs - a guy who specialized in human interfaces - expressed some interest in the system. When he heard that the system was programmed in basic he turned to his neighbour and said 'We have to stop these people from programming in basic'. and then walked away. The system was used in a number of shows in Toronto and then the concept was adopted by another company and made into a successful product. At the time, I thought of your point: people liked those Basic languages (which does have some appalling shortcomings as a language) for a number of good reasons - they were a friendly development environment, and easy to interface to assembly language. Furthermore, you couldn't get any other language for the Commodore PET. A competent engineer works with what they have available. Incidentally, a modern version of Basic is Tcl/Tk, which has many of the same properties that made Basic popular. So, it is an interesting challenge to the language writers to create something that has the power of the C language and still does (say) automatic checking of array bounds. Peter On Wed, Dec 03, 2003 at 11:30:28PM -0500, Henry Spencer wrote: > On Wed, 3 Dec 2003, Peter Hiscocks wrote: > > This exploit, like others against Unix machines many years ago, was based on > > a buffer overflow dumping the user into supervisor space. > > Actually, no, as I understand it (with the caveat that I haven't really > gone investigating), this one is *not* a buffer overflow, exactly. It's > the result of *integer* overflow in (essentially) a buffer-overflow check. > A language with automatic buffer-overflow checks could easily have the > same vulnerability, if the implementor wasn't careful. > > > This, in turn, is > > a direct result of the fact that the C programming language does not check > > or enforce limits on a string length or buffer size - that's left up to the > > individual programmer. > > As has often been said, C gives you all the rope you need to hang yourself. > > > After all, C is not so much a systems programming language as a high-level > > version of assembly language. > > Oddly enough, it has pushed most "real" systems programming languages out > of the business. And this is *not* because of sharp marketing tactics or > firm backing by a big organization or dot-com hype -- quite the contrary. > It succeeded because people with work to do find it easier to get results > in C than in "real" systems programming languages, and so it spread and > prospered despite inept or nonexistent marketing, uncertain support, and a > marked dearth of hype. > > It behooves people who aspire to design systems programming languages to > *PAY* *ATTENTION* *DAMMIT*, rather than just casting aspersions on the > intelligence and judgement of the customer. It is their own damn fault; > their languages keep failing, and C keeps succeeding despite its nasty > flaws, because they keep ignoring the needs of the real language users. > People went with C because it did what they wanted, instead of telling > them they shouldn't want that. > > > Years ago, Philipe Khan of Borland said that 'C is a disease and the > > Americans are spreading it.' Maybe he had this kind of thing in mind. > > I don't think it is impossible to keep C's virtues while eliminating its > more grievous faults. But it will not be done by people who look down > their long aristocratic noses at C, and scorn it as a peasant's language > of no interest to them. > > Henry Spencer > henry-lqW1N6Cllo0sV2N9l4h3zg at public.gmane.org > > > -- > 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 -- Peter D. Hiscocks Department of Electrical and Computer Engineering Ryerson University, 350 Victoria Street, Toronto, Ontario, M5B 2K3, Canada Phone: (416) 979-5000 Ext 6109 Fax: (416) 979-5280 Email: phiscock-g851W1bGYuGnS0EtXVNi6w at public.gmane.org URL: http://www.ee.ryerson.ca/~phiscock -- 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 joehill-rieW9WUcm8FFJ04o6PK0Fg＠public.gmane.org 04 Dec '03

04 Dec '03

On Thu, 04 Dec 2003 08:28:41 -0500 Jason Shein <jason-gaRZxGPHtpBxZtjKW1aY+1aTQe2KTcn/(a)public.gmane.org> wrote: > You can get the Macromedis Flash rpm's here > > http://sluglug.ucsc.edu/macromedia/site_ucsc.html > > > And mozplugger if you do not already have it installed > > http://freshmeat.net/redir/mozplugger/37064/url_rpm/mozplugger-1.3.2-1.i586… Got 'er all workin' fine now, I wasn't paying attention (surprise) and missed Lloyd's link to libstdc++2.10, once I got that installed it was good to go. Thanks! -- JoeHill ++ ICQ # 280779813 Registered Linux user #282046 Homepage: www.orderinchaos.org +++++++++++++++++++++++++++ "I have the South in front of me and the bankers behind me -- and for my country, I fear the bankers most."-- Abraham Lincoln -- 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 jason-gaRZxGPHtpBxZtjKW1aY+1aTQe2KTcn/＠public.gmane.org 04 Dec '03

04 Dec '03

You can get the Macromedis Flash rpm's here http://sluglug.ucsc.edu/macromedia/site_ucsc.html And mozplugger if you do not already have it installed http://freshmeat.net/redir/mozplugger/37064/url_rpm/mozplugger-1.3.2-1.i586… JoeHill wrote: > 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. > -- " Eventually people tire of repairing broken Windows, And decide to replace them with something stronger" (o_ //\ Linux - The Choice Of A GNU Generation V_/_ Jason Shein Linux Registered User #281100 jason-gaRZxGPHtpBxZtjKW1aY+1aTQe2KTcn/(a)public.gmane.org -- 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

Got a license for that Code?
by joehill-rieW9WUcm8FFJ04o6PK0Fg＠public.gmane.org 04 Dec '03

04 Dec '03

"It looks like the Microsoft front organizations are pushing licensing for software writers. Of course, the usual suspects, the BSA and ITAA are involved in writing the laws." Link: http://newsvac.newsforge.com/article.pl?sid=03/12/03/1640223 -- JoeHill ++ ICQ # 280779813 Registered Linux user #282046 Homepage: www.orderinchaos.org +++++++++++++++++++++++++++ "Behind every great fortune is a crime." -- Balzac -- 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

Multiple USB keyboards ?
by tim-s/rLXaiAEBtBDgjK7y7TUQ＠public.gmane.org 04 Dec '03

04 Dec '03

William Park <opengeometry-FFYn/CNdgSA at public.gmane.org> writes: > I have multiple video cards (agp, pci) and multiple mouses (serial, > ps/2, usb) working independently. That is, I can choose which should be > selected when bringing up X. > > But, multiple keyboards are all shared; so, you can press keys from any > keyboard. How do you get them working independently? By having a separate XF86Config for each keyboard, mouse, and video card combination. Each XF86Config would have its own InputDevice sections for its respective keyboard and mouse. The trick is to know which device (in /dev) represents which keyboard or mouse. This is obviouse if you have say one PS/2 keyboard, one USB keyboard, one PS/2 mouse, and one USB mouse. But it's tricky if you have multiple USB keyboards and mice since they will be assigned entries in /dev/input dynamically. As long as you keep them permanently plugged in, you should be able to figure out what's what by trial and error. Note, while I have used USB keyboards and mice, I haven't tried this type of setup so YMMV. Good luck, -- tim writer <tim-s/rLXaiAEBtBDgjK7y7TUQ at public.gmane.org> starnix inc. 905.771.0017 ext. 225 thornhill, ontario, canada http://www.starnix.com professional linux services & products -- 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

C considered harmful: was Debian attacker may have used new exploit
by tim-s/rLXaiAEBtBDgjK7y7TUQ＠public.gmane.org 04 Dec '03

04 Dec '03

Marcus Brubaker <marcus.brubaker-H217xnMUJC0sA/PxXw9srA at public.gmane.org> writes: > On Wed, 2003-12-03 at 22:55, Peter Hiscocks wrote: > > OK, I hate to flog a dead horse but really: > > > > Hmmmm, this is likely to start a looooong drawn out flame thread. > Language arguments almost always do. So, with trying to prevent that in > mind, I will avoid standing up for my general language of choice and > instead offer an alternative. > > > This exploit, like others against Unix machines many years ago, was based on > > a buffer overflow dumping the user into supervisor space. This, in turn, is > > a direct result of the fact that the C programming language does not check > > or enforce limits on a string length or buffer size - that's left up to the > > individual programmer. > > > > Surely, given the importance of security, it should be possible to fix the C > > language (or my preference, use a different one) to do systems programming. > > After all, C is not so much a systems programming language as a high-level > > version of assembly language. > > > > "Fixing" C in the sense you're imagining will never happen and people > often do use other languages for specific tasks. However, other > languages are not immune to buffer overflows as most of them are > actually written in C themselves. Not immune but still resistant. Typical C programs are full of calls to "dangerous" functions like strcpy() and sprintf(), as well as direct pointer manipulations. While language interpreters are no different, their cores tend to be quite small compared with modern behemoths and are well tested both with comprehensive test suites, which accompany most decent languages, and via applications written in the language. The flip side of course is that a buffer overflow (or similar problem) in a language implementation has the potential to affect all applications deployed in that language, so the impact could be much more widespread than a buffer overflow in a given C application. > The better solution is things like stackguard[1] and execshield[2] which > actually fix the root problem: the stack should NOT be executable and > neither should most of the heap and likewise portions of memory which > are actively executable shouldn't be writable from userspace. Maybe. Some language environments rely on an executable stack to implement trampolines. An executable heap could be useful in languages with just-in-time compilation or dynamic loading of compiled code, although I don't know if any language implementations use such techniques. -- tim writer <tim-s/rLXaiAEBtBDgjK7y7TUQ at public.gmane.org> starnix inc. 905.771.0017 ext. 225 thornhill, ontario, canada http://www.starnix.com professional linux services & products -- 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

C considered harmful: was Debian attacker may have used new exploit
by tim-s/rLXaiAEBtBDgjK7y7TUQ＠public.gmane.org 04 Dec '03

04 Dec '03

Marcus Brubaker <marcus.brubaker-H217xnMUJC0sA/PxXw9srA at public.gmane.org> writes: > On Wed, 2003-12-03 at 23:30, Henry Spencer wrote: > > On Wed, 3 Dec 2003, Peter Hiscocks wrote: > Hell, even Prolog and the many species of LISP-type-languages are > interesting in their own right (though not terribly useful in my mind). LISP not useful? Sacrilege! I'm responding to this with Gnus, still arguably one of the best mail/news clients, running within Xemacs, still arguably one of the best programmers' editors (vi/emacs flame wars notwithstanding), written in a dialect of LISP. > But if you fit well into a specific category of application development > then there is a whole host of better choices for you. For instance, next > major GUI application I write will probably be in Java [....] You might find this article, by one of the LISP community's greats, both interesting and on topic: http://www.paulgraham.com/javacover.html -- tim writer <tim-s/rLXaiAEBtBDgjK7y7TUQ at public.gmane.org> starnix inc. 905.771.0017 ext. 225 thornhill, ontario, canada http://www.starnix.com professional linux services & products -- 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 robert-5LEc/6Zm6xCUd8a0hrldnti2O/JbrIOy＠public.gmane.org 03 Dec '03

03 Dec '03

On Wed, 3 Dec 2003, JoeHill wrote: > Like to have the last word, eh? No, I just find repeating myself on mailing lists to be a waste of time. I found I so many better uses for the time. Ok, so I replied :) I'm gone now. Please feel free to have the last word, it won't bother me a bit. Rob -- Robert Brockway B.Sc. email: robert-5LEc/6Zm6xCUd8a0hrldnti2O/JbrIOy at public.gmane.org, zzbrock at uqconnect.net Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah -- 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

C considered harmful: was Debian attacker may have used new exploit
by marcus.brubaker-H217xnMUJC0sA/PxXw9srA＠public.gmane.org 03 Dec '03

03 Dec '03

On Wed, 2003-12-03 at 23:30, Henry Spencer wrote: > On Wed, 3 Dec 2003, Peter Hiscocks wrote: > > This exploit, like others against Unix machines many years ago, was based on > > a buffer overflow dumping the user into supervisor space. > > Actually, no, as I understand it (with the caveat that I haven't really > gone investigating), this one is *not* a buffer overflow, exactly. It's > the result of *integer* overflow in (essentially) a buffer-overflow check. > A language with automatic buffer-overflow checks could easily have the > same vulnerability, if the implementor wasn't careful. > Interesting, this is certainly a less common form of exploit... > > After all, C is not so much a systems programming language as a high-level > > version of assembly language. > > Oddly enough, it has pushed most "real" systems programming languages out > of the business. And this is *not* because of sharp marketing tactics or > firm backing by a big organization or dot-com hype -- quite the contrary. > It succeeded because people with work to do find it easier to get results > in C than in "real" systems programming languages, and so it spread and > prospered despite inept or nonexistent marketing, uncertain support, and a > marked dearth of hype. > > It behooves people who aspire to design systems programming languages to > *PAY* *ATTENTION* *DAMMIT*, rather than just casting aspersions on the > intelligence and judgement of the customer. It is their own damn fault; > their languages keep failing, and C keeps succeeding despite its nasty > flaws, because they keep ignoring the needs of the real language users. > People went with C because it did what they wanted, instead of telling > them they shouldn't want that. > Honestly, I don't think there will be a language to supplant C as a *systems* programming language in general any time soon. Frankly, systems programming too frequently requires breaking the rules that other languages commonly enforce. There have been a lot of great languages developed out there for specific tasks. Perl is gorgeous for text processing, as is python I've heard. BASH is fair for simple task automation, and tolerable for slightly more complicated tasks. Matlab is a GODSEND for anyone doing algorithm prototyping and other kinds of scientific computation. Java is worlds beyond C++ when it comes to OOP. Hell, even Prolog and the many species of LISP-type-languages are interesting in their own right (though not terribly useful in my mind). The point though is that for applications where you need the kind of flexibility (or rope...heh) that C offers, there has yet to be any good substitutes. But if you fit well into a specific category of application development then there is a whole host of better choices for you. For instance, next major GUI application I write will probably be in Java or maybe C++ with a good widget library (GTKmm). It just hurts too much to write GUI apps in C. > > Years ago, Philipe Khan of Borland said that 'C is a disease and the > > Americans are spreading it.' Maybe he had this kind of thing in mind. > > I don't think it is impossible to keep C's virtues while eliminating its > more grievous faults. But it will not be done by people who look down > their long aristocratic noses at C, and scorn it as a peasant's language > of no interest to them. One mans grievous fault is another mans shiningly useful feature. Language wise I think there is really only a few things that can/should be done to improve C. Largely they involve incorporating the more sensible improvements from C++ and dropping most of the cruft. I.E. compile-time operator overloading would be nice but templates are horrendous. Beyond that though I think C would benefit most from more code reuse. Why is it that everyone has their own C libraries to handle strings? Things like Glib need to be more widely used, because otherwise we're all just reinventing the wheel and reproducing the bugs. -- Marcus Brubaker <marcus.brubaker-H217xnMUJC0sA/PxXw9srA at public.gmane.org> -- 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