- Legacy - lists.gtalug.org

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 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

1 0

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

03 Dec '03

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

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 05:11:38PM -0500, JoeHill wrote: > 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 ;-) You have argued against *any* limit. Until the "slippery slope" statment above, I have not seen any *justification* for such an argument that actually applied to delayed disclosure (a temporary limit for a deliberate purpose) rather than *only* to non-disclosure. A slippery slope argument is not particularly compelling unless you go on to show that there is difficulty in choosing any point in between the extremes and sticking to that point. As long as people *do* always come to the point where they disclose the problem, there is no slippery slope. Different people may have different amounts of leniency, but the end result is the same except for the exact timing. If you have any argument that justifies immediate disclosure over delayed disclosure, please state it. What penalty is there for making it possible to have a fix for a problem available before the general publication of the problem, as long as the publication will happen in a relatively short time frame? What benefit comes from not providing a window of time for fixing the problem before disclosure? But skip "non-disclosure is bad" arguments - they do not say anything against delayed disclosure. And skip "nobody has proved it is necessary" arguments - they at most say that immediate disclosure might not cause damage, but they do not state any advantage for immediate disclosure. -- 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

MisterHouse / x10 /home automation
by MichaelGalea-4VtgCsEi+FIybS5Ee8rs3A＠public.gmane.org 03 Dec '03

03 Dec '03

> -----Original Message----- > From: Mailing List [mailto:tlug-KfBRzk3UKwol8X4E99VVQg at public.gmane.org] > Sent: Wednesday, December 03, 2003 10:11 AM > To: tlug-lxSQFCZeNF4 at public.gmane.org > Subject: [TLUG]: MisterHouse / x10 /home automation > > > Has anyone used x10 or home automation in > their house? Where is a good place to > shop for x10 stuff? Any recommendations? > > Robert > -- I use it to turn a fan on in my attack, and it has worked reliably for three seasons now. I used an x10 motion sensor to turn on a lamp in my hall at night so my kids wouldn't go bouncing into things on the way to the loo.. Somewhere in my neighborhood, someone else started to experiment with x10 and turned my tv set on a few times (select an original house/device code and you can get around that..) All that having been said, the technology has no capability for error detection and retransmission and I never considered it reliable, or used it for anything I really needed to depend upon. The fact that you can't pull data with it, just push doesn't help either.. -- 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

2 1

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

03 Dec '03

OK, I hate to flog a dead horse but really: 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. 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. Peter (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.) On Wed, Dec 03, 2003 at 10:22:01PM -0500, Tom Legrady wrote: > When the thread gets around to Hitler, the horse is not only dead, but > already boiled down for glue. > > Next topic, please. > > Tom > > >On Wed, Dec 03, 2003 at 05:11:38PM -0500, JoeHill wrote: > > > > > >>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 ;-) > >> > >> > > -- > 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

Debian attacker may have used new exploit
by legrady-bJEeYj9oJeDQT0dZR+AlfA＠public.gmane.org 03 Dec '03

03 Dec '03

When the thread gets around to Hitler, the horse is not only dead, but already boiled down for glue. Next topic, please. Tom >On Wed, Dec 03, 2003 at 05:11:38PM -0500, JoeHill wrote: > > >>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 ;-) >> >> -- 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

SMC Cable/DSL 4port router
by james.knott-bJEeYj9oJeDQT0dZR+AlfA＠public.gmane.org 03 Dec '03

03 Dec '03

Tim Writer wrote: > > Yes, that's how I've configured it too. It just bothers me that a product > labeled "firewall" has such limited firewalling capabilities. And if you've > got a Linux firewall, it's not too hard to throw in a wireless card and do it > "properly". > It does have firewall capabilities, which are fine if you're just connecting it to a high speed line and don't worry about wireless security. However, I'd have preferred to have a firwall on the wireless side. -- 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

mdk kernel enterprise src?
by aacton-B71PBEe7S7Y＠public.gmane.org 03 Dec '03

03 Dec '03

On Wed, 2003-12-03 at 19:17, Lloyd D Budd wrote: > ...err, now I think I understand... the source files end up in > /usr/src/RPM/SOURCES , no entry is made in rpm db , and from here I > could extract the kernel source tar files or what ever I want to... Umm, I guess so, but that's not what you want to do. That tarball will not contain any Mandrake-specific modifications. It is pristine. If you want kernel modules you build yourself to insert into the Mandrake kernel, you'll need to build them against the Mandrakized kernel source. Just install the kernel-source RPM and Bob's your uncle. It will drop into /usr/src/linux. Austin -- Austin Acton Synthetic Organic Chemist, Teaching Assistant, Ph.D. Candidate Department of Chemistry, York University, Toronto MandrakeLinux Volunteer Developer, homepage: www.groundstate.ca -- 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

mdk kernel enterprise src?
by lloyd-fEEwcc3XMu8jODpR/OX0VQ＠public.gmane.org 03 Dec '03

03 Dec '03

On Wed, 2003-12-03 at 18:55, Austin wrote: > On Wed, 2003-12-03 at 18:11, Lloyd D Budd wrote: > > I see there is > > kernel-2.4.22.21mdk-1-1mdk.src.rpm (39303204) > > kernel-source-2.4.22-21mdk.i586.rpm (42200593) > > > > I wonder about the size difference :-( > > You realize that these are not the same thing, right? Having never made an RPM, I had thought I had... I had thought that kernel.src.rpm would have about the same contents as kernel-source.rpm . I had thought that src.rpm might possibly be a little larger, but not the other way around... Still I should be able to install kernel-2.4.22.21mdk-1-1mdk.src.rpm ? ...err, now I think I understand... the source files end up in /usr/src/RPM/SOURCES , no entry is made in rpm db , and from here I could extract the kernel source tar files or what ever I want to... -- 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

mdk kernel enterprise src?
by aacton-B71PBEe7S7Y＠public.gmane.org 03 Dec '03

03 Dec '03

On Wed, 2003-12-03 at 18:11, Lloyd D Budd wrote: > I see there is > kernel-2.4.22.21mdk-1-1mdk.src.rpm (39303204) > kernel-source-2.4.22-21mdk.i586.rpm (42200593) > > I wonder about the size difference :-( You realize that these are not the same thing, right? kernel.src.rpm is the RPM source; it's used by RPM makers to make RPMs (compilation instructions, etc.) kernel-source.i586.rpm is a package containing the kernel source code itself (installs to /usr/src/linux) It looks like the one you downloaded is corrupt maybe? Try kernel-source from http://mandrake.redbox.cz/Mandrake/updates/9.2/RPMS/ Austin -- Austin Acton Synthetic Organic Chemist, Teaching Assistant, Ph.D. Candidate Department of Chemistry, York University, Toronto MandrakeLinux Volunteer Developer, homepage: www.groundstate.ca -- 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