- Legacy - lists.gtalug.org

C considered harmful: was Debian attacker may have used new exploit
by fraser-Txk5XLRqZ6CsTnJN9+BGXg＠public.gmane.org 04 Dec '03

04 Dec '03

On December 4, 2003 12:56 pm, Marcus Brubaker wrote: > > You might find this article, by one of the LISP community's greats, both > > interesting and on topic: > > > > http://www.paulgraham.com/javacover.html > > To each their own opinion but if you want to do OOP then there really > isn't a better language out there than Java. Do people write real software with java or is still just web stuff? -- Fraser Campbell <fraser-Txk5XLRqZ6CsTnJN9+BGXg at public.gmane.org> http://www.wehave.net/ Georgetown, Ontario, Canada Debian GNU/Linux -- 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 opengeometry-FFYn/CNdgSA＠public.gmane.org 04 Dec '03

04 Dec '03

On Thu, Dec 04, 2003 at 05:08:40AM -0500, Tim Writer wrote: > 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. Found it! -- http://cambuca.ldhs.cetuc.puc-rio.br/multiuser/ I got this working on my Slackware-9.1, kernel-2.4.23, and XFree86-4.3.0. Key insights are - modprobe -r keybdev - modprobe evdev -- William Park, Open Geometry Consulting, <opengeometry-FFYn/CNdgSA at public.gmane.org> Linux solution for data management and processing. -- 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 jingsu-26n5VD7DAF2Tm46uYYfjYg＠public.gmane.org 04 Dec '03

04 Dec '03

> Dynamic code generation (program writes code then jumps to it) sounds like a > really useful facility for virus writers, trojan horses and worms. In what > circumstance is it necessary to have that capability? Dynamic run-time optimization. Hot field of research (though I know nothing about it). -- 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 phiscock-g851W1bGYuGnS0EtXVNi6w＠public.gmane.org 04 Dec '03

04 Dec '03

Dynamic code generation (program writes code then jumps to it) sounds like a really useful facility for virus writers, trojan horses and worms. In what circumstance is it necessary to have that capability? Isn't it much safer to have a rigid demarcation between code generation and code execution? Then the operating system can do run-time checks on the thing it's about to execute. Peter On Thu, Dec 04, 2003 at 06:46:40PM -0500, Henry Spencer wrote: > But it's not clear to me that this really improves things much. If you > can overwrite control information, e.g. a function return address -- which > is generally needed to *exploit* an executable stack or heap -- then you > can always look around for places where you could branch to existing code > that happens to do what you want. (For example, functions which do > dynamic code generation will have a strong tendency to end with the > sequence "tell the system to make the heap region pointed to by register X > executable; return".) > > 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

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

04 Dec '03

On 4 Dec 2003, Tim Writer wrote: > 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. It has definitely been done, although I'm not up to date on current examples. I think it would not be difficult to exclude executable code from the stack, given some design attention to it, but there are a number of dynamic-code-generation techniques which really need the ability to make portions of the heap executable. Mind you, just a non-executable stack would solve a lot of problems. You can envision more complicated solutions in which you could ask the kernel to make part of the heap executable but read-only: you do your dynamic code generation first, but you have to make the resulting code read-only before you can run out of it. In fact, you may need to interact with the kernel at that point *anyway*, to make sure that caches are flushed properly, so the overhead may be minimal. But it's not clear to me that this really improves things much. If you can overwrite control information, e.g. a function return address -- which is generally needed to *exploit* an executable stack or heap -- then you can always look around for places where you could branch to existing code that happens to do what you want. (For example, functions which do dynamic code generation will have a strong tendency to end with the sequence "tell the system to make the heap region pointed to by register X executable; return".) 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

video plugin for mozilla on linux
by anton-F0u+EriZ6ihBDgjK7y7TUQ＠public.gmane.org 04 Dec '03

04 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 <http://plugindoc.mozdev.org/linux.html> has very good instructions for using plugins under Linux. Especially video ones. - -- Anton Markov <("anton" + "@" + "truxtar" + "." + "com")> GnuPGP Key fingerprint = 5546 A6E2 1FFB 9BB8 15C3 CE34 46B7 8D93 3AD1 44B4 ~ "The difference between insanity and genius is measured only by success." ~ - Some bad guy from 007 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/z8KMRreNkzrRRLQRAhNKAJ4lWFiw4HCb+x8pMyj3ECUgQRiygACeKQbL sMeczNeVDEOF89HKWwbN2c8= =B0Tt -----END PGP SIGNATURE----- -- 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

OOP, Was: C considered harmful: was Debian attacker may have used new exploit
by jingsu-26n5VD7DAF2Tm46uYYfjYg＠public.gmane.org 04 Dec '03

04 Dec '03

> > Yes, and the processing overhead for an addition is about the same as for > > a square root extraction. An "I'm feeling Lucky" on google over "smalltalk performance overhead" seems to provide a page with a simple micro-benchmark that refutes the "add" overhead example. Certainly it's not as fast as assembler, but comparing it to the cost of square rooting seems to be much. http://www.exept.de/sites/exept/onlineDoc/english/programming/STspeed.html DISCLAIMER: I'm no language expert, I have no real-world experience with Smalltalk, and I do not know the latest research in language performance/correctness/tradeoff issues (citeseer seems to provide many many links on this subject, though I haven't taken the time to wade through it). -- 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 jmm-TU2q2He6PgRlD5gtYiU6kEEOCMrvLtNR＠public.gmane.org 04 Dec '03

04 Dec '03

On Thu, Dec 04, 2003 at 01:42:39PM -0500, Anthony de Boer wrote: > Peter Hiscocks wrote: > > 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. > > This idea may be fine within an application, but it breaks down at > security boundaries like the user/kernel interface, since the kernel had > better not trust the user program's claim of the size of an array (this > being an approximation of how Debian got burned), also since the kernel > is dynamically carving out chunks of memory for things, and since "one > man's program is another man's data" (the whole program may be one array > of mere data to the kernel). > > There's a lot that can be fixed with opaque handles to structures (eg. > Dan Bernstein's string library as opposed to the traditional C library's > simple char * string implementation); C++ formalizes some such ideas, > but a prudent C programmer can write better code without needing C++'s > extra baggage. Not only does language provided bounds checking fail to be useful in this instance, it is this sort of case where it often can get in the way. Not only does the kernel code have to convert and validate pointer values between user space representation and kernel representation but (in the case of language enforced bounds checking) it would also have to convert the bounds info as well as the address, *and then convince the language that it is allowed to use the converted result. Often, languages that try to prevent errors do not provide a way to cheat (i.e. compose a "pointer" by hand). -- 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 henry-lqW1N6Cllo0sV2N9l4h3zg＠public.gmane.org 04 Dec '03

04 Dec '03

On Thu, 4 Dec 2003, John Macdonald wrote: > ... *and then convince the language that it is allowed to use > the converted result. Often, languages that try to > prevent errors do not provide a way to cheat (i.e. > compose a "pointer" by hand). The ones that are intended for systems programming generally do provide a way to do it, although it may be encapsulated in a special "low-level operations" library rather than being something you can casually do in one line of source code. (That encapsulation is probably a good thing. C's big problem is not that it can do bizarre stuff, but that the compiler can't tell whether that's what you really wanted. You *can* write a bounds-checking C compiler -- there is nothing in the standard C language that prevents it -- but because it's so hard to tell what the programmer is up to, such an implementation has to use worst-case strategies that impose heavy run-time overheads.) System calls generally are invoked via library routines anyway. If worst comes to worst, those routines can be written in assembler, so they can cheat as required. (That's how things were done in the original Unix C implementation on the pdp11, in fact, because the system-call calling conventions had been designed for use from assembler and weren't a good match to C.) 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

SOT: shitfs in spam trends and topics
by cbbrowne-HInyCGIudOg＠public.gmane.org 04 Dec '03

04 Dec '03

> Another trend, although a somewhat longer one and at a low level of > occurrence, are penis enlargement ads that have taken to insulting me. > "Satisfy your woman, you pin-dick" was the most harsh, and perhaps > relatedly, the funniest one as well. If aggressive derision toward a > potential customer helps make you money then I should have been rich > long ago! Hmm... Let me visit folder +Spam/Snakeoil... Hmmm... - One "degree mill" - One "INFO ABOUT YOUR COLON" - A couple of "eBay Auction seminars" - Several "online prescription" notes - Five about copying DVDs - I wonder what "Gain 2-3 inches before X-Mas" might be? :-) And a dozen others that I don't feel like working further to identify. The odd trend I have been seeing is for there to be large numbers of spam messages that seem totally futile. There's no way of contacting them to buy their services. No URLs. No valid return address. No way for the message to be of any value whatever, supposing I _did_ want to increase my breasts by a couple of sizes. -- output = reverse("ac.notelrac.teneerf" "@" "454aa") http://www3.sympatico.ca/cbbrowne/lsf.html "Sponges grow in the ocean. I wonder how much deeper the ocean would be if that didn't happen." -- Steven Wright -- 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