Follow Slashdot stories on Twitter


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re:You're still doing that? (Score 1) 274

The worst part about donating isn't the lingering banners (adblock can be set to take care of them easily). It's the WMF spam. I donated once, a mistake I'll never make again. Once I donated, I was automatically subscribed to a "donators" mailing list, which they used to bombard me with requests to ask my friends to donate, subscribe to a recurring donation model, etc.. Instead, I told my friends that if they donate to Wikipedia, they'll have to deal with such unsavory practices.

Comment Re:Requiring encryption server-side (Score 1) 245

Since you're having trouble reading between the lines, I'll explain:

1. Unfortunate client is set to prefer (not require) encryption.
2. Client connects to server.
3. Client sends STARTTLS request.
4. MITM rejects STARTTLS request.
5. Client sends AUTH command, with username and password, over unencrypted channel.
6. Server rejects unencrypted AUTH command.
7. MITM issues STARTTLS request.
8. MITM issues AUTH command with the password it just stole.

This can, incidentally, be done over any public network by a MITM. Rejecting that unencrypted AUTH command helps combat users who disable (or don't enable) encryption in their clients, simply because they'll try it once, then enable encryption when they can't send mail (hopefully it isn't too late at that point). But it does nothing against users with mail clients that are not set to require that encryption succeed. It does nothing to address the case of the ISP stripping STARTTLS requests.

Comment Re:Yes, after all... (Score 0, Offtopic) 114

The GNOME foundation invented the word—nay, the letters themselves, carved and finished from wordstone hewn from the deep tunnels of the earth.

s/Whirlpool/Whole Foods/

Clearly, all trademarks should be meaningless and indefensible.

Comment Re:Requiring encryption server-side (Score 1) 245

I dealt with this by setting my mail server up so that an authenticated connection's required for outgoing user e-mail through it, and encryption's required before the client can authenticate.

So, when the client sends AUTH PLAIN <b64-encoded username+password>, and your server rejects the request because it isn't encrypted, you're happy with this result?

Comment Authentication (Score 4, Informative) 245

Stripping out STARTTLS may mean that you can't authenticate to the mail server --- which is frequently required --- over an encrypted channel. Some unfortunate individuals set (or don't unset) an option that tells their e-mail clients that encryption is preferred, but not required, which they assume to be sufficient --- because they know that their mail server supports encryption. When those individuals use an ISP that strips out STARTTLS, they are transmitting authentication data in plaintext. Still don't feel like getting angry?

Comment Not an inherent problem. (Score 5, Informative) 18


First of all, this isn't new. Hell, it's in the RFC. In fact, the RFC specifically details and recommends protecting against it in several places.

This is an implementation problem, not really anything to do with OAuth 2.0 or OpenID-Connect. Authorization servers are supposed to match the redirect_uri against valid values that are registered by the client. This is inconvenient for redirecting users back to the right page, so some popular providers decided to match based on prefix or domain, instead. And some websites on the internet have open redirects (hard to believe, i know). If the client website's security is _really_ lousy^H^H^H^H^H lax, its OAuth2 callback module might also not validate the response URI when it gets the access code, and may even not strip the access code from the URI parameters when redirecting.

The service providers are supposed to require clients to register a full redirection callback. The clients can keep track of whatever page people are on with the state parameter. But those same clients, with that same terrible security, will probably get that wrong, too.

So, it's entirely a known problem, and what it boils down to is this: You can recommend best practices, but you can't fix stupid. That's why Google and Facebook are shrugging it off.

That said, if they performed some meager sanitization, it could go a long way to improve the situation.

Comment Re:Mountain out of a molehill (Score 5, Interesting) 239

It's worse than that. Most browsers don't check certificate revocation lists, and the certificate authority might not have a CRL infrastructure in place that can support the number of revoked certs generated by this incident.

Granted, they could take the money they receive from all the reissued certificates and use it to build such an infrastructure, but they probably won't.

Web-SSL was already a broken system. Now that it's been cracked open even wider, maybe we can throw it out and implement something better.

Oh, who am i kidding? We'll just pretend everything's okay again after most people have patched the hole.

Comment Not exactly a molehill. (Score 2) 239

There are many organizations that not only can't patch, do not know how to patch, or simply haven't completed patching, but also don't _have_ an IPS or IDS in place. In fact, even if a company is in a position (and has the know-how) to install one, using either one of these options may come with what is perceived as an unacceptable performance impact.

I managed to write an exploit for this issue within about 30 minutes. The bug is almost trivial to exploit. In my meager tests, i gathered usernames, passwords, session cookies, and oauth2 client tokens from an unrelated location on the internet. So, yes, i'd say the issue leans a bit closer to mountain than molehill.

That said, the fix is also trivial, and the fact that several distributions still don't have updated packages is downright embarrassing.

Comment Re:Situation is a Shambles (Score 5, Interesting) 239

This is not a memory management issue per se, and has nothing to do with mmap or malloc. In fact, the malloc succeeds just fine. Rather than just explaining in text, it might be easier if i simplify the issue in C parlance (this would look neater if slashdot allowed better code formatting):

char *rec_p = record; // record pointer
uint16_t rec_len = SSL3_RECORD_LEN; // hi! i'm ignored.
uint16_t user_len = *(uint16_t*)rec_p; // user_len = user-supplied length
rec_p += sizeof(uint16_t); // rec_p points to start of user payload
char *buf = malloc(user_len); // allocate using user-supplied length
memcpy(buf, rec_p, user_len); // copy user_len bytes from record
reply(buf); // reply with said data

Due to the fact that this code works more or less exactly as designed, the exploit functions across architectures and operating systems. This bug is so amateurish, i almost find it difficult to believe that it was unintentional.

Comment Re:It could work securely (Score 1) 192

Most keys marked "Do Not Duplicate" are not standard keys. Assuming that the kiosk carries only certain types of blanks instead of fully machining each key from a block (likely, but unspecified in TFA), it shouldn't be able to duplicate non-standard or "security" or vehicle keys anyway.

If you happen to have a normal house key marked "Do Not Duplicate", and you really want to duplicate it anyway, ten minutes with some sandpaper will take care of that problem, and then any random locksmith will do.

Comment Re:A whole lot of crimes need stiffer sentences (Score 5, Insightful) 260

Holy bad example, Batman! A guy who robs a liquor store for $100 doesn't get 20 years for stealing $100. He gets 20 years for pointing a gun at the liquor store attendant and threatening his life for personal gain. Possibly as a repeat offender.

What a lot of commenters don't seem to get is that the sort of pollution that hardcore offenders engage in over there often results in human deaths. So the potential for punishment is merely being brought in line with the crime. You won't deter serious polluters with a fine.

That said, sure, many crimes are not proportional to their sentences. No news here. While we're making improbable demands, i think the act of spitting chewing gum on the street or sidewalk should be treated as vandalism, and enforced accordingly.

Comment Re:Note PWM LED issues (Score 1) 375

This. Sort of. Well, almost. You started off on the right track, anyway. But neither "top end Dell" nor "$1000 Eizo" will get you a monitor without PWM.

For the uninitiated, PWM stands for Pulse Width Modulation, and essentially, the PWM component blinks the LED backlight quickly in order to dim the brightness. The dimmer your backlight, the longer the "off" time. Sometimes, PWM use causes a perceptible flicker. What is perceptible and what isn't is subjective, however, and sometimes the flicker is imperceptible to a person, but still causes eye strain. Some PWMs blink faster than others, and faster-blinking units are generally regarded as easier on the eyes. Note that the use of a PWM isn't necessary -- LEDs _can_ dim, but since LEDs don't have linear electricity->lumens output and dimmer LEDs can experience a color shift, it's the easy way out. Most monitor backlight engineers take it.

I'm quite sensitive to PWM flicker. LED monitors especially tend to drive me nuts, so I did my research on this.

A couple of months ago, I compiled a list of no-PWM monitor options, from scouring,, and message boards around the internet. My criteria:
- IPS, or comparable (though all TN panels would use PWM anyway)
- no PWM, period -- not even really, really fast ones.
- preferably non-glossy, but any options will be considered.
- minimum resolution: 1920x1080

That's it. No size restrictions. These are the options I came up with:
- Dell U2713HM
- HP zr2740w
- Samsung S27B970D
- ViewSonic VP2770-LED

[Note that the Samsung, while it doesn't utilize typical PWM tech, does fluctuate according to some tests. For this reason, I did not consider it further.]

I found it interesting that all options were 27".

I, personally, bought the HP zr2740w, and I enjoy coding on it quite a bit. It's worlds easier on my eyes than any LCD monitor I've used in the past. Newer models such as mine (which was made in late 2012) apparently have a less aggressive anti-glare coating than older versions. Fine text is crisp using either gray-on-black (my preference) or black-on-white (the web's preference). White screens do not seem at all "dirty", as some people complain about the older revision.

Slashdot Top Deals

Intel CPUs are not defective, they just act that way. -- Henry Spencer