/* Increase the size of the buffer and retry. */ buffer->alloc += len + 32768;
It looks like the problem here is that buffer->alloc (which presumably stores the size of the buffer) grows on every try, while the actual size of the buffer grows only on successful tries. So you could have a situation where, after a couple of tries, the buffer is 65536, but buffer->alloc is 98304. This could potentially cause another part of the program to run past the actual end of the buffer.
The patch addresses this by only updating buffer->alloc after the new memory has been successfully allocated.
With BSD-style licenses, commercial companies can use your code without having to distribute the source. Your hard work can then be used by a company to profit without any acknowledgement of the true author of the code.
This is really just not true at all. Below is an excerpt from the BSD license:
* Copyright (c) 1982, 1986, 1990, 1991, 1993 * The Regents of the University of California. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution.
Note that you've got to reprint the copyright regardless of whether you distribute in source or binary form. As long as you put your name in the copyright when you release your stuff under the BSD license, you'll get acknowledgement. That's kind of the point of the license actually: there are no restrictions on use beyond giving credit where it's due.
Well, sendmail in OpenBSD is configured by default to listen only on the loopback interface, so their claim of 'Only one remote hole in the default install, in more than 7 years!' is still true.
This vulnerability wouldn't be a remote hole in the default install.
OTOH, it seems to me that some other model, such as a scheme that gives legitimate senders explicit advance AUTHORIZATION to send you email, might be what's needed.
I understand what you're saying, but there are a couple of problems with this, depending on how you implement it. If you allow potential correspondents to request authorization by email, you'll still have to process at least one message per originating address. That obviously won't work to eliminate spam (or even cut it down to size...) The other option is to force potential correspondents to request authorization over another channel (phone, fax, whatever), but this neatly destroys a lot of the convenience of email. It also eliminates the impersonal nature of email (by forcing a personal contact) when it is partly this impersonality that distinguishes it in the first place (and encourages some first time correspondents to make contact at all...)
May not be the ultimate filter (and I doubt it could be), but it's real interesting, I think, that this appears to have considerably greater than zero accuracy.
Actually, the Bayesian filter implemented by POPFile is remarkably accurate. A friend of mine has been using it since it debuted on slashdot in November and it has correctly classified all of the spam he's received since (76% of his email in total, unfortunately...)
You can also set up POPFile to process the headers of your messages as well as the body, so it will effectively learn the email addresses of people you're willing to receive email from anyway. Depending on how you define words (what you use as token separators), you could attempt to make it generalize to domains as well.
It is all in mp3 or ogg format and it is all from CDs that I personally own or have borrowed from friends (emphasis added)
Ummm...this is illegal, dude. There's no problem borrowing you're friend's CD to listen to it, but making a COPY is a violation of COPYright.
Not in Canada, it isn't. We pay a levy (that goes directly to music publishers) every time we purchase recordable media. In exchange, we can make copies of CDs (and not just CDs we own) for personal use (so I can't, for example, make copies and sell or probably even give them away...)
Some details are here: http://pcbuyersguide.com/hardware/storage/2003_Lev y_FAQ.html.
Note particularly question 18 and the answer. Also note that even though the date says 2003, that's only because there's a proposed rate increase. We've been paying this levy since 1998 or so. The link I had for the full text of the Copyright Act, including the amendments from 1998, unfortunately appears to be broken, but if you can find it, the relevant text is in Part VIII: Private Copying.
What kind of programming challenge uses a one-based array?
Actually, in this case it's a great idea. The game world is bounded by walls, so you can put the walls in the 0 index (and the width+1 index) of your array and not have to explicitly test for the array bounds. Treat them like any other wall.
Many of the features described above as 'missing' from Google are in fact there, often in exactly the same form they're described in. For those (including the submitter) who can't be bothered to explore new tools, here's a quick run-down...
the ability to exclude as well as include terms in your query. AltaVista lets you use minus signs and plus signs to indicate what you really don't want and what you do want
Google in fact lets you do exactly the same thing. There's an example in rebuttal to another point later on, so I'll leave it at that.
At AltaVista, I can search for +link:samizdat.com -host:samizdat.com and get exactly what I want -- finding out who thinks enough of my pages to have linked to me without my having contacted them
Strangely, Google allows an eerily similar query: try +link:samizdat.com -site:samizdat.com (note the plus and minus I promised earlier...)
At AltaVista, however, I can search for host:samizdat.com and get a complete list of all the pages at my site that are in the AltaVista index.
Okay, admittedly this one's a little different, but it is possible. Try site:samizdat.com +samizdat.com
So Google would seem to do everything the submitter is looking for as well as having a more efficient ranking system. The recent 'abuses' of the Pagerank system are nothing compared to the flood of porn sites that once greated anyone who searched with a few common keywords.
Re:Please stop writing network apps in C!
on
OpenSSH Local Root Hole
·
· Score: 5, Insightful
Did you even look at the patch?
--- channels_old.c Mon Mar 4 02:07:06 2002 +++ channels.c Mon Mar 4 02:07:16 2002 @@ -151,7 +151,7 @@ channel_lookup(int id) { Channel *c; - if (id < 0 || id > channels_alloc) { + if (id < 0 || id >= channels_alloc) { log("channel_lookup: %d: bad id", id); return NULL; }
You want to explain to me how any "modern safe language" is going to stop me from saying 'greater-than', when I really mean 'greater-than-or-equal-to'?
Every time I played on Battle.net, anyone with half a brain simply played the Zerg and rushed the hell out of everyone else. Usually, the Zerg won.
That hasn't been true since Brood War was released (1.04 patch for Starcraft also slowed down the Zerg considerably). Personally, I think StarCraft/Brood War is an amazing example of balancing three wildly different races.
"Well," I have to ask, with a rather pensive look on my face. "If the people who designed and wrote the software can't find the bugs, what makes you think that throwing somebody at it in their spare cycles is going to help? We want software that works, so we can do our business. Our business is not writing this software."
"Given enough eyeballs, all bugs are shallow."
The idea is that if everybody gets to see the code, the problem will be obvious to somebody. It certainly stands a better chance of being found than if only the original coders (who might not see anything wrong -- after all, they wrote it that way in the first place) get to look under the hood.
I don't see this as a big deal (or a big problem) at all. If you simply prefaced the name of each module with the fully qualified domain name of the server it happens to be sitting on, you'd accomplish this painlessly. This is already recommended practice for third-party Java developers (a package called 'widget' developed at acme.com would be called com.acme.widget)
Play poker against the computer...
on
Arguing A.I.
·
· Score: 1
PokiBot is a poker-playing AI developed at the University of Alberta in Edmonton. You can play Poki these days through a Java applet at the link above, but back in the day Poki was always on IRC, bilking the tourists out of their (admittedly play-money) bankrolls. Early versions of PokiBot had problems (for a long time he was a terrible sucker for a check-raise), but in the days just before the majority of IRC poker players left for the online cardrooms, he was quite impressive.
Of course, this is in a medium uniquely suited to computer players. Some of the most difficult problems in AI are in computer vision, although in certain limited problem spaces (including recognizing emotions by modeling human facial expressions -- looking for a reference on this: some group in Japan, I think...) significant progress has been made.
However, unless one is talking about a gene that has been modified, genes are no more inventions than elements are.
Well, in this case, that is exactly what one is talking about. The only successful patents thus far have been on modified genetic strains (Vitamin A enriched rice, the cancer-prone mouse from Harvard, etc.)
No, but that's not exactly the point the original poster was making anyway. His point more directly translates to 'a stupid user implies a user friendly OS'. And that's something that's defensible. Ubiquitousness aside, Microsoft attracts more stupid users because the learning curve is more accomodating. You can usually count on a certain level of competency in a Linux user because it requires more than a few clicks to make anything useful happen. Not that that's a virtue of the operating system, but it does serve to raise the bar a little bit...
As it turns out, MS Security is not as bad as Sun's or IBM's [objectwatch.com] The article is toward the bottom of the page. It's mostly about exploits via buffer overflow. But, as a Linux Zealot may not know, MS actually writes some of the more solid code.
That is, to put it politely, complete bunk.
Microsoft's biggest problem is not buffer overflows. You don't need to sneak a virus through the basement window when you can drive it in through the front door, waving merrily as you go. Many of Microsoft's biggest security problems have been with viruses that simply take advantage of what they're explicitly allowed to do. Most Outlook viruses don't exploit low-level coding errors, they exploit the high-level error of allowing arbitrary foreign executables free access to the system. Ditto with Office macro viruses. I wouldn't call that solid coding. Solid coding means preparing for the eventuality that your users are naive and making it as hard as possible for them to shoot themselves (or their neighbours, in the case of Melissa, et. al.) in the foot.
I'm not saying that Sun or IBM are any better, but saying that Microsoft writes solid code is absolutely ludicrous.
What makes goat milk so special for spider silk production?
From another article in Forbes:
Turner got the idea while teaching at McGill University in Montreal in 1992, after learning that scientists had isolated three spider genes that code for silk proteins. "It was a purely serendipitous find. The silk gland of spiders and the milk gland of goats are almost identical. Teats equal spinnerets."
The advantages of goats over cows are detailed in another reply.
Yeah, it seemed to me that the requirement that you be able to write into process memory made this a no-op. It's kind of like a way to pick a lock that requires you to already be on the inside of the door. If you can write into process memory, don't you already pretty much have the keys to the kingdom? But it's not the easiest thing to get.
Assuming anonymous upload was allowed, couldn't you just upload a file containing your shell code? Presumably this has to be read from the socket and written to disk, passing through the process's memory in the process (maybe only one buffer worth, but you can get a lot done in a few bytes of shell code...)
I really have no idea here, having never tried to do anything of this nature before, but it seems to me that getting a couple of dozen bytes into a semi-predictable area of memory isn't the hardest part of exploiting this bug. The part I don't get is the part alluded to by the great-grandparent of this post -- namely, how to get malicious data into the unitialized area of the heap.
Re:don't jump to conclusions:
on
Apocalypse 3
·
· Score: 1
Alternate perl 5 solutions below:
Concatenating two arrays together:
@array1 = (@array1, @array2);
Setting an element to the first defined item:
$element = (grep defined, ($a, $b))[0] || 'default';
note that this last example is also generalizable to lists of arbitrary length...
Slashdot Mirror
The bug must center around this line:
It looks like the problem here is that buffer->alloc (which presumably stores the size of the buffer) grows on every try, while the actual size of the buffer grows only on successful tries. So you could have a situation where, after a couple of tries, the buffer is 65536, but buffer->alloc is 98304. This could potentially cause another part of the program to run past the actual end of the buffer.
The patch addresses this by only updating buffer->alloc after the new memory has been successfully allocated.
This is really just not true at all. Below is an excerpt from the BSD license:
Note that you've got to reprint the copyright regardless of whether you distribute in source or binary form. As long as you put your name in the copyright when you release your stuff under the BSD license, you'll get acknowledgement. That's kind of the point of the license actually: there are no restrictions on use beyond giving credit where it's due.
Way offtopic here now, but it was Ken Thompson, not Donald Knuth. Here's the discussion in question: Reflections on Trusting Trust.
Also a summary entry in the Jargon File, for those who don't want to read the paper: http://www.catb.org/~esr/jargon/html/entry/back-do or.html
This vulnerability wouldn't be a remote hole in the default install.
Lisa acid trips by drinking the water... giving rise to two of my favourite quotes:
"Have her take these, and these... oh, and these."
"Oh, thank you doctor!"
"Oh, I'm not a doctor."
And my absolute favourite line ever:
"Can't talk, coming down."
I understand what you're saying, but there are a couple of problems with this, depending on how you implement it. If you allow potential correspondents to request authorization by email, you'll still have to process at least one message per originating address. That obviously won't work to eliminate spam (or even cut it down to size...) The other option is to force potential correspondents to request authorization over another channel (phone, fax, whatever), but this neatly destroys a lot of the convenience of email. It also eliminates the impersonal nature of email (by forcing a personal contact) when it is partly this impersonality that distinguishes it in the first place (and encourages some first time correspondents to make contact at all...)
Actually, the Bayesian filter implemented by POPFile is remarkably accurate. A friend of mine has been using it since it debuted on slashdot in November and it has correctly classified all of the spam he's received since (76% of his email in total, unfortunately...)
You can also set up POPFile to process the headers of your messages as well as the body, so it will effectively learn the email addresses of people you're willing to receive email from anyway. Depending on how you define words (what you use as token separators), you could attempt to make it generalize to domains as well.
Never eat at a place called Mom's.
Never play cards with a man called Doc.
And never lie down with a woman who's got more troubles than you...
Not in Canada, it isn't. We pay a levy (that goes directly to music publishers) every time we purchase recordable media. In exchange, we can make copies of CDs (and not just CDs we own) for personal use (so I can't, for example, make copies and sell or probably even give them away...)
Some details are here: http://pcbuyersguide.com/hardware/storage/2003_Lev y_FAQ.html.
Note particularly question 18 and the answer. Also note that even though the date says 2003, that's only because there's a proposed rate increase. We've been paying this levy since 1998 or so. The link I had for the full text of the Copyright Act, including the amendments from 1998, unfortunately appears to be broken, but if you can find it, the relevant text is in Part VIII: Private Copying.
Actually, in this case it's a great idea. The game world is bounded by walls, so you can put the walls in the 0 index (and the width+1 index) of your array and not have to explicitly test for the array bounds. Treat them like any other wall.
No pictures/videos at the site mentioned in the article, but here's a different site with videos of a capacitor-powered gauss gun in action:
Many of the features described above as 'missing' from Google are in fact there, often in exactly the same form they're described in. For those (including the submitter) who can't be bothered to explore new tools, here's a quick run-down...
Google in fact lets you do exactly the same thing. There's an example in rebuttal to another point later on, so I'll leave it at that.
Strangely, Google allows an eerily similar query: try +link:samizdat.com -site:samizdat.com (note the plus and minus I promised earlier...)
Okay, admittedly this one's a little different, but it is possible. Try site:samizdat.com +samizdat.com
So Google would seem to do everything the submitter is looking for as well as having a more efficient ranking system. The recent 'abuses' of the Pagerank system are nothing compared to the flood of porn sites that once greated anyone who searched with a few common keywords.
Did you even look at the patch?
--- channels_old.c Mon Mar 4 02:07:06 2002
+++ channels.c Mon Mar 4 02:07:16 2002
@@ -151,7 +151,7 @@
channel_lookup(int id)
{
Channel *c;
- if (id < 0 || id > channels_alloc) {
+ if (id < 0 || id >= channels_alloc) {
log("channel_lookup: %d: bad id", id);
return NULL;
}
You want to explain to me how any "modern safe language" is going to stop me from saying 'greater-than', when I really mean 'greater-than-or-equal-to'?
Newton, not Edison.
Catflap, not dog door.
Gravity, not electricity.
Inner door, outer door -- arguably could be interpreted as a 'door within a door', I guess.
Been awhile since you read the book? Nice try all the same.
The most recent one (AFAIK) is called Tourist. Great disk. Listening to it here at work even as I type, oddly...
That hasn't been true since Brood War was released (1.04 patch for Starcraft also slowed down the Zerg considerably). Personally, I think StarCraft/Brood War is an amazing example of balancing three wildly different races.
"Given enough eyeballs, all bugs are shallow."
The idea is that if everybody gets to see the code, the problem will be obvious to somebody. It certainly stands a better chance of being found than if only the original coders (who might not see anything wrong -- after all, they wrote it that way in the first place) get to look under the hood.
I don't see this as a big deal (or a big problem) at all. If you simply prefaced the name of each module with the fully qualified domain name of the server it happens to be sitting on, you'd accomplish this painlessly. This is already recommended practice for third-party Java developers (a package called 'widget' developed at acme.com would be called com.acme.widget)
PokiBot is a poker-playing AI developed at the University of Alberta in Edmonton. You can play Poki these days through a Java applet at the link above, but back in the day Poki was always on IRC, bilking the tourists out of their (admittedly play-money) bankrolls. Early versions of PokiBot had problems (for a long time he was a terrible sucker for a check-raise), but in the days just before the majority of IRC poker players left for the online cardrooms, he was quite impressive.
Of course, this is in a medium uniquely suited to computer players. Some of the most difficult problems in AI are in computer vision, although in certain limited problem spaces (including recognizing emotions by modeling human facial expressions -- looking for a reference on this: some group in Japan, I think...) significant progress has been made.
Well, in this case, that is exactly what one is talking about. The only successful patents thus far have been on modified genetic strains (Vitamin A enriched rice, the cancer-prone mouse from Harvard, etc.)
No, but that's not exactly the point the original poster was making anyway. His point more directly translates to 'a stupid user implies a user friendly OS'. And that's something that's defensible. Ubiquitousness aside, Microsoft attracts more stupid users because the learning curve is more accomodating. You can usually count on a certain level of competency in a Linux user because it requires more than a few clicks to make anything useful happen. Not that that's a virtue of the operating system, but it does serve to raise the bar a little bit...
That is, to put it politely, complete bunk.
Microsoft's biggest problem is not buffer overflows. You don't need to sneak a virus through the basement window when you can drive it in through the front door, waving merrily as you go. Many of Microsoft's biggest security problems have been with viruses that simply take advantage of what they're explicitly allowed to do. Most Outlook viruses don't exploit low-level coding errors, they exploit the high-level error of allowing arbitrary foreign executables free access to the system. Ditto with Office macro viruses. I wouldn't call that solid coding. Solid coding means preparing for the eventuality that your users are naive and making it as hard as possible for them to shoot themselves (or their neighbours, in the case of Melissa, et. al.) in the foot.
I'm not saying that Sun or IBM are any better, but saying that Microsoft writes solid code is absolutely ludicrous.
Forgot the link:
http://www.forbes.com/global/2001/0219/061.html
From another article in Forbes:
The advantages of goats over cows are detailed in another reply.
Assuming anonymous upload was allowed, couldn't you just upload a file containing your shell code? Presumably this has to be read from the socket and written to disk, passing through the process's memory in the process (maybe only one buffer worth, but you can get a lot done in a few bytes of shell code...)
I really have no idea here, having never tried to do anything of this nature before, but it seems to me that getting a couple of dozen bytes into a semi-predictable area of memory isn't the hardest part of exploiting this bug. The part I don't get is the part alluded to by the great-grandparent of this post -- namely, how to get malicious data into the unitialized area of the heap.
Alternate perl 5 solutions below:
Concatenating two arrays together:
@array1 = (@array1, @array2);
Setting an element to the first defined item:
$element = (grep defined, ($a, $b))[0] || 'default';
note that this last example is also generalizable to lists of arbitrary length...