Fast Pay "Exploit"

Please keep personal disputes out of this thread or it will be closed.

Now that I know what this "bug" is...


The best answer from those in the know would have been: "The bug allows the user to replace the set price in the pay dialog with whatever they care to use, in effect reverting the window to the "old style" with a value entry box." and I'd have added: "It's a very simple bug that should not have affected any vendor properly scripted."


All the talk-without-saying-anything got me thinking there'd come some way of making the vendor think the user had sent more L$ than they actually had... a magic money making scenario that really would have been a major big deal. As is, and as I first said, the amount reported in the money() event was always what the user actually sent. Thus, scarecely a bug or exploit of the SL side as much as the vedor's side.

I still think releasing the information would still be the best course to minimize the actual damage done, while the window of opportunity is still here. But, I'm not gonna... if the "fix" for this minor teeny bug is that close, there's no point.

I'm glad to hear that it's just UI manipulation / loopholes, for which there is a way of detecting via LSL. I'd post the particulars of my exploit but it would lead to a dramatic increase in its use (as present there are no reported cases) and more importantly there is no defense agaisnt it. LL traditionaly has been very lax about client side security. Thier attitude has been "someone will figure out how anyway, so lets not bother adding security", which is maddening when you report issues and they go unresolved; I've been the keeper of one for over a year. I discovered it during research into the client. I had a number of discussions with LL. The result of which was I mothballed my research. Thier attitude lead me to feel that when push came to shove, and things boil down to money, I was going to be at the wrong end of the DMCA.

People will always be able to hack the Fast Pay buttons & text feild. People are out there right now, reverse engineering & hacking the client. This is the biggest argument for Trusted Computing. You shouldn't trust the client; its not secure.

When you look at the big picture, this can be viewed as run of the mill. Low priority interface loophole. Mine like yours is an interface issue (as llSetPayPrice is an interface function), but in this case it doesn't fit with thier attitude.

Either start queieng up with the

"oops - sorry we were mistaken" type posts

or I will post enough of your own contradictary posts and replies to make Torley enact her threat.

Then I shall formerly, in writing to Linden Labs, demand an apology from the Moderator involved in this thread.

So basically the moderator is saying is that, despite their assurance that there is no bug in llSetPayPrice, depite their near-perfect 20-20 hindsight in remembering that they were going to mention people should include a check in pay when they were writing the wiki, and despite them telling someone else to stop saying there is a bug in said function - that actually there is an anomaly.

As there seems to be some confusion over the length of this post regarding the words bug, fault, exploit, mistake, or drama I think the moderator should at least expand on which they have found the non-existant anomaly to be - bug-exploit-fault ( possibly with an explanation of each term so that we know where to catagorize anomalies in future )

Also as a representative of Linden Labs on their own site the moderator is actually telling customers that they shouldn't trust anything Linden say as Linden's response is liable to be "let's not bother".

I will not cover the subject of trolling as I will be dealing with that in a seperate formal complaint to Linden Labs when they tell me what format they would like it in.

The moderator is also saying that they will not publicize any details of said anomaly as it could possibly harm SL customers - despite allowing ( as a moderator ) several pages of such demands to go unchecked when this very same stance was taken by someone else.

Finally to totally contradict themselves in the same post, they attempt to write off the anomaly as a low priority loophole - which badgers me to believe that they are not going to stick by their assurance that it will be fixed in the near future, and that they have, in fact, come to the same conclusion I came to several days ago - that the best way to deal with it is to warn others how to safe guards themselves about it and not to publish any specific details they have about it.

I am so glad there is no confusion over the subject now.

Please don't, Torley. There's only one troll here and most of us are ignoring her. The thread has been extremely useful to many of us fans of this forum.

Well I had not seen this thread before today so I went in SL a minute ago to try and find what this bug is about. I nailed it in my first attempt. Nobody was harmed in the proces, the vendor was owned by a friend who I immediately IM'd so that the vendor can be upgraded.

My personal take on it:
- It's an extremely silly UI bug which does not require any skill. Many people will have found it by accident. If this isn't widespread yet it's a miracle.
- It's extremely sad that people actually coded vendors that can be fooled by this.

Personally I'd be ashamed if anything I created was vulnerable. Are there any vendor coders except for JEVN that do not check the amount people pay?

Probably not, most venders predate llSetPayPrice, and it's loopholes. I cannot imagine anyone removing code from their vender software to added llSetPayPrice, really it's just a one liner in the display update code.

Well I've found 1 other and I really wonder if it isn't more widespread than one would expect. There are quite a few things out there that have fastpay implemented. Maybe some people figured it was a great way to reduce the size of their code.

I found another one, I really think this is more widespread than you'd expect. Apparently a lot of coders are not security aware. Note that no only vendors use fastpay. This can effectivly ruin people (I've just told somebody how to check all of his devices)

Like I said before, I was writing a vendor before I saw this thread, a new vendor, I knew about llSetPayPrice, and I did plan on using it in my vendor design as a customer convenience. At NO TIME did I ever think that its use would obviate the need to verify the amount paid in the money() event. Maybe it is because I am a noob scripter, and I don't know all the ways someone can pay me; maybe it was my nearly 30 years of programming experience telling me subconsciously "don't trust anything, especially unprotected client-side software, when it comes to money". However, I don't think was either. I think that anyone with enough basic experience in programming would have designed in a check, because it seems the right thing to do, not only to catch system bugs, but even his/her own foibles.

It is IRRELEVANT whether there is a UI bug or not. There is nothing in the Wiki about llSetPayPrice that indicates it is a guaranteed secure payment method (and, being a client-side function, I would SEVERELY doubt it even if it did say that). The ONLY issue is whether there is a bug in the money amount reported to the money() event handler (IE, it reports a larger different value paid than was actually transferred to my account). All other claims of "exploit! exploit!" are redundant and unnecessary, and no amount of hand-waving or shouting "fire!" is going to change that.

Lastly, it is poor form to find a bug or exploit in the game, post about it in a public forum and then say "I can't reveal details". If it is something that cannot be disclosed, then DO NOT DISCLOSE IT, ANY OF IT, PERIOD! If you think that someone else needs to know besides the Lindens, then tell them in private. Doing otherwise does nothing but cause strife and, I think, is grounds for censure by the Lindens. Staff members should be above such actions, as they should be setting the example for good behavior, being held to a higher standard.

Now, as we've beaten this horse to death, let's get back to talking about fixing what we know about, and leave the posturing, ego-soaked flame posts behind us.

And as I've also said, I use both since a very quick check on a multivendor set up revealed a flaw... This is apparently different to the other "bug" but the same fix works for both, so there you go.

The reason I use llSetPayPrice() - I set it with precisely one button of the expected price and with the space to put your own number in blanked out - it's another way of telling people how much the item costs without ambiguity. The vendor displays the price etc. too, but people however you do it manage to not see, hear, whatever the price - click pay and no praying, there's the price too...

As soon as this "exploit" (in the client side user interface?) is "fixed" I can post a tutorial how to get around it if anyone believes the fix is going to make a difference.

One word, Ollydbg.

MC Seattle,

exactly. There are many things I can think of that could be used to hack this. Off course they will be less widespread but as long as devices exist that rely on the UI to stop people from paying the wrong amount there will be exploits. This should be killed at the root by using sane coding.

ROFL! The irony is so thick I can't breathe.

well 3, but its a bit more elegant than that.

I don't want to reveal too much of what our code does, as we kinda came up with the concept, and theres quite a bit we do that is not done elsewhere yet. I will say that since I enacted our new vendor code last summer, I have never had a single customer complaint in regards to a purchase problem caused by the vendor itself, or any interference thereof.

And we're doing 3-4x the business now that we were before, and before, i was getting 3-5 IM's a day.

doing the math, over the last 200 days, thats potentially up to 4000 less problems that people have had thanks to the LW vend 2.0 system. (and 4000 less support issues i have had to spend time resolving).

If there is sufficient interest, and sufficient work done in the SL community to match the system we have created... Around the time it turns a year old, I may take a second look at public domaining at least some parts of the LW 2.0 code

never rely on a UI widget to manage your interaction with code. If you want someone to pay you $539 for your new widget...

Check the price, if they pay too little, refund them the difference and ask them to pay the proper amount.

If they pay too much, give them their widget, and refund them the difference.

Its not only going to save you alot of trouble, its just bloody common courtesy to refund someone who does not pay with 'exact change'. While adding a button to allow them to do that with a single click is cool, the code underneath it should still be just as solid as it would have been with a (_______) dialog.

ATTENTION TO ALL DESIGNERS AND CREATORS:

THIS PERSON WHOM I HAVE NAME....IS PLACING INVISIBLE FASTPAY PRIMS OVER OUR ITEMS... BASICALLY WHEN A CUSTOMER PAYS..THIS PERSON WHO PLACED THE FAST PAY MACHINE OVER THE DESIGNERS ITEM GET THE MONEY.. NOT THE CREATOR AND WORSE.. THE CUSTOMER DOES NOT GET THE ITEM THEY JUST PAID FOR! I KNOW WE ARE NOT TO MENTION NAMES IN THE FORUMS.. BUT I WANT YOU GUYS TO KNOW WHO THIS IS AND TO BAN THIS PERSON OFF YOUR LAND. I HAVE ALREADY REPORTED THIS TO THE LINDENS REPORT AND I HOPE THEY DO SOMETHING ABOUT THIS PERSON.

THIS PERSONS NAME IS : [edited]

THIS IS THE RESPONSE I HAVE RECIEVED FROM [edited] AFTER HE LEARNED HE WAS CAUGHT.....

[4:12] [edited]: (Saved Wed May 24 23:43:50 2006) You caught me, I would rate you if I could from the profile pages. Well done.


******************BEWARE-BEWARE-BEWARE-BEWARE**********************

Thanks for the heads up.

It never ceases to amaze me... the level of dishonesty and stupidity of some people.

This thread is locked for Linden Review.


Torley Linden:
This thread remains closed. The useful discussion already took place despite some unfortunate personal disputes. A shame it was woken from its slumber and had to be closed like this--stating you're aware of the forum Guidelines is good, but only if you can follow them.