Enable Javascript to access this page. Arena of An Artist: problem
rss
twitter
    Find out what I'm doing, Follow Me :)
Showing posts with label problem. Show all posts
Showing posts with label problem. Show all posts

Saturday, November 6, 2010

Google pays for finding bugs in orkut, youtube, blogger etc.

Rewarding web application security research


 http://www.google.co.in/images/logos/ps_logo2.png
Back in January of this year, the Chromium open source project launched a well-received vulnerability reward program. In the months since launch, researchers reporting a wide range of great bugs have received rewards — a small summary of which can be found in the Hall of Fame. We've seen a sustained increase in the number of high quality reports from researchers, and their combined efforts are contributing to a more secure Chromium browser for millions of users.

Today, we are announcing an experimental new vulnerability reward program that applies to Google web properties. We already enjoy working with an array of researchers to improve Google security, and some individuals who have provided high caliber reports are listed on our credits page. As well as enabling us to thank regular contributors in a new way, we hope our new program will attract new researchers and the types of reports that help make our users safer.

In the spirit of the original Chromium blog post, we have some information about the new program in a question and answer format below:

Q) What applications are in scope?
A) Any Google web properties which display or manage highly sensitive authenticated user data or accounts may be in scope. Some examples could include:

* *.google.com
* *.youtube.com
* *.blogger.com
* *.orkut.com

For now, Google's client applications (e.g. Android, Picasa, Google Desktop, etc) are not in scope. We may expand the program in the future.

Q) What classes of bug are in scope?
A) It's difficult to provide a definitive list of vulnerabilities that will be rewarded, however, any serious bug which directly affects the confidentiality or integrity of user data may be in scope. We anticipate most rewards will be in bug categories such as:

* XSS
* XSRF / CSRF
* XSSI (cross-site script inclusion)
* Bypassing authorization controls (e.g. User A can access User B's private data)
* Server side code execution or command injection

Out of concern for the availability of our services to all users, we ask you to refrain from using automated testing tools.

These categories of bugs are definitively excluded:

* attacks against Google’s corporate infrastructure
* social engineering and physical attacks
* denial of service bugs
* non-web application vulnerabilities, including vulnerabilities in client applications
* SEO blackhat techniques
* vulnerabilities in Google-branded websites hosted by third parties
* bugs in technologies recently acquired by Google

Q) How far should I go to demonstrate a vulnerability?
A) Please, only ever target your own account or a test account. Never attempt to access anyone else's data. Do not engage in any activity that bombards Google services with large numbers of requests or large volumes of data.

Q) I've found a vulnerability — how do I report it?
A) Contact details are listed here. Please only use the email address given for actual vulnerabilities in Google products. Non-security bugs and queries about problems with your account should should instead be directed to the Google Help Centers.

Q) What reward might I get?
A) The base reward for qualifying bugs is $500. If the rewards panel finds a particular bug to be severe or unusually clever, rewards of up to $3,133.7 may be issued. The panel may also decide a single report actually constitutes multiple bugs requiring reward, or that multiple reports constitute only a single reward.

We understand that some researchers aren’t interested in the money, so we’d also like to give you the option to donate your reward to charity. If you do, we'll match it — subject to our discretion.

Regardless of whether you're rewarded monetarily or not, all vulnerability reporters who interact with us in a respectful, productive manner will be credited on a new vulnerability reporter page. If we file a bug internally, you'll be credited.

Superstar performers will continue to be acknowledged under the "We Thank You" section of this page.

Q) How do I find out if my bug qualified for a reward?
A) You will receive a comment to this effect in an emailed response from the Google Security Team.

Q) What if someone else also found the same bug?
A) Only the first report of a given issue that we had not yet identified is eligible. In the event of a duplicate submission, only the earliest received report is considered.

Q) Will bugs disclosed without giving Google developers an opportunity to fix them first still qualify?
A) We believe handling vulnerabilities responsibly is a two-way street. It's our job to fix serious bugs within a reasonable time frame, and we in turn request advance, private notice of any issues that are uncovered. Vulnerabilities that are disclosed to any party other than Google, except for the purposes of resolving the vulnerability (for example, an issue affecting multiple vendors), will usually not qualify. This includes both full public disclosure and limited private release.

Q) Do I still qualify if I disclose the problem publicly once fixed?
A) Yes, absolutely! We encourage open collaboration. We will also make sure to credit you on our new vulnerability reporter page.

Q) Who determines whether a given bug is eligible?
A) Several members of the Google Security Team including Chris Evans, Neel Mehta, Adam Mein, Matt Moore, and Michal Zalewski.

Q) Are you going to list my name on a public web page?
A) Only if you want us to. If selected as the recipient of a reward, and you accept, we will need your contact details in order to pay you. However, at your discretion, you can choose not to be listed on any credit page.

Q) No doubt you wanted to make some legal points?
A) Sure. We encourage broad participation. However, we are unable to issue rewards to individuals who are on sanctions lists, or who are in countries (e.g. Cuba, Iran, North Korea, Sudan and Syria) on sanctions lists. This program is also not open to minors. You are responsible for any tax implications depending on your country of residency and citizenship. There may be additional restrictions on your ability to enter depending upon your local law.

This is not a competition, but rather an experimental and discretionary rewards program. You should understand that we can cancel the program at any time, and the decision as to whether or not to pay a reward has to be entirely at our discretion.

Of course, your testing must not violate any law, or disrupt or compromise any data that is not your own.

Thank you for helping us to make Google's products more secure. We look forward to issuing our first reward in this new program.

Tuesday, May 18, 2010

Year 2038 problem



The year 2038 problem (also known as Unix Millennium Bug, Y2K38 by analogy to the Y2K problem) may cause some computer software to fail before or in the year 2038. The problem affects all software and systems that store system time as a signed 32-bit integer, and interpret this number as the number of seconds since 00:00:00 UTC on Thursday, 1 January 1970. The farthest time that can be represented this way is 03:14:07 UTC on Tuesday, 19 January 2038. Times beyond this moment will "wrap around" and be stored internally as a negative number, which these systems will interpret as a date in 1901 rather than 2038. This will likely cause problems for users of these systems due to erroneous calculations.
Further, while most programs will only be affected in or very close to 2038, programs that work with future dates will begin to run into problems much sooner. For example, a program that works with dates 20 years in the future will have to be fixed no later than in 2018.
Because most 32-bit Unix-like systems store and manipulate time in this format, it is usually called Unix time, and so the year 2038 problem is often referred to as the Unix Millennium Bug. However, any other non-Unix operating systems and software that store and manipulate time this way will be just as vulnerable.

Early problems

In May 2006, reports surfaced of an early manifestation of the Y2038 problem in the AOLserver software. The software was designed with a kludge to handle a database request that should "never" time out. Rather than specifically handling this special case, the initial design simply specified an arbitrary time-out date in the future. The default configuration for the server specified that the request should time out after one billion seconds. One billion seconds (approximately thirty-two years) after 9:27.28 pm on 12 May 2006 is beyond the 2038 cutoff date. Thus, after this time, the time-out calculation overflowed and returned a date that was actually in the past, causing the software to crash. When the problem was discovered, AOL's server managers had to edit the configuration file and set the time out to a lower value.

Solutions

There is no straightforward and general fix for this problem for existing CPU and operating system combinations, existing file systems, or existing binary data formats. Changing the definition of time_t data type to a 64-bit type would break binary compatibility for software, data storage, and may affect any code that deals with the binary representation of time. Changing time_t to an unsigned 32-bit integer, effectively allowing timestamps to be accurate until the year 2106, would affect programs that deal with time differences or dates before 1970, and thus would also break binary compatibility in many cases.
Most operating systems for 64-bit architectures already use 64-bit integers in their time_t, and these operating systems are becoming more common, particularly in desktop and server environments. Using a (signed) 64-bit value introduces a new wraparound date that is over twenty times greater than the present age of the universe: approximately 292 billion years from now, on Sunday, December 4, 292,277,026,596 AD. As of 2007, however, hundreds of millions of 32-bit systems are deployed, many in embedded systems, and it is far from certain that they will all be replaced by 2038. Additionally, 32-bit applications running on 64-bit systems are likely to be affected by the issue.
Despite the modern eighteen-to-twenty-four-month generational update in computer systems technology, embedded computers may operate unchanged for the life of the system they control. The use of 32-bit time_t has also been encoded into some file formats, which means it can live on for a long time beyond the life of the machines for which such file formats were originally designed.
Alternative proposals have been made (some of which are in use) including storing either milliseconds or microseconds since an epoch (typically either 1 January 1970 or 1 January 2000) in a signed-64 bit integer, providing a minimum of 300,000 years range. Other proposals for new time representations provide different precisions, ranges, and sizes (almost always wider than 32 bits), as well as solving other related problems, such as the handling of leap seconds.

Thursday, March 11, 2010

140 tech experts to follow on Twitter

Twitter can be a valuable tool for techies — if you know who to follow. Here is a list of 140 of the top technology experts, journalists, and thought leaders you’ll can find on Twitter, updated for 2010.

So here is the list, which is not ranked 1-140 but simply listed in alphabetical order. If there are others you think should be added to the list, make a note in the comments.

-Chris Anderson (@chr1sa) Editor in Chief of Wired and author of The Long Tail

-Michael Arrington (@techcrunch) Founder of TechCrunch

-Matt Asay (@mjasay) COO of Ubuntu and Open Source columnist for CNET

-John Battelle (@johnbattelle) Author and pundit on Google and Internet search

-Veronica Belmont (@veronica) Host of Tekzilla and Qore, and former CNET TV host

-Randall Bennett (@randallb) Founder of TechVi; former CNET TV producer

-David Berlind (@dberlind) TechWeb Editor-in-Chief

-Tim Berners-Lee (@timberners_lee) Inventor of the World Wide Web

-Ryan Block (@ryan) Former Engadget editor and co-founder of GDGT

-Henry Blodget (@hblodget) Controversial Wall Street journalist who covers tech sector

-Danah Boyd (@zephoria) Academic/researcher in new media

-Ed Bott (@edbott) Microsoft Windows expert, blogger, book author

-Paul Boutin (@paulboutin) Reporter for VentureBeat, The New York Times, and Wired

-Tony Brandley (@tonys3kur3) Freelance tech writer speciallizing in security

-Rick Broida (@cheapskateblog) CNET blogger scours the Web looking for the best
deals in tech

-Jason Calacanis (@jasoncalacanis) CEO of Mahalo, founder of Weblogs Inc.

-Pete Cashmore (@mashable) CEO of Mashable

-Bonnie Cha (@bonniecnet) CNET mobile phone pundit

-Jacqui Cheng (@eJacqui) Associate editor for Ars Technica

-Robert Cringley (@cringely) Long-time technology writer and pundit

-Brian Cooley (@briancooley) CNET car-tech editor

for others go herehttp://blogs.zdnet.com/BTL/?p=31704&tag=nl.e539