Tweets by @buherablog
profile for buherator at IT Security Stack Exchange, Q&A for IT security professionals

A BitBetyár Blog

Túljártál a nagyokosok eszén? Küldd be a mutatványodat! (e-mail a buherator gmailkomra jöhet)

Full-Disclosure / Névjegy / Coming out


Promó

H.A.C.K.

Címkék

0day (110) adobe (87) adobe reader (21) anonymous (26) apple (60) az olvasó ír (49) blackhat (20) botnet (22) bug (200) buherablog (44) buhera sörözés (39) bukta (49) deface (38) dns (22) dos (29) esemény (82) facebook (26) firefox (64) flash (33) gondolat (31) google (59) google chrome (36) hacktivity (37) hírek (117) incidens (224) internet explorer (88) iphone (35) java (50) jog (22) kína (21) kriptográfia (68) kultúra (21) linux (24) malware (43) microsoft (142) móka (48) mozilla (23) office (26) oracle (40) os x (43) patch (197) php (20) politika (31) privacy (58) programozás (22) safari (34) sql injection (62) windows (85) xss (77) Címkefelhő

Licensz

Creative Commons Licenc

A PHP és a Java közös pontja

2011.02.01. 18:33 | buherator | 17 komment

 ... mindkettő beledöglik a  2.2250738585072011e-308 számba.

(-1) küldte a hírt, hogy a január elején itt is szóba került PHP problémához kísértetiesen hasonlót fedeztek fel a legújabb java futtatókörnyezetben és a fordítóban is!

Az ExploringBinary cikke a következő két egyszerű forráskódot tette közzé a hiba demonstrálására, az első osztály a JRE-t, a másik a javac-t fekteti meg:

class runhang {
public static void main(String[] args) {
  System.out.println("Test:");
  double d = Double.parseDouble("2.2250738585072012e-308");
  System.out.println("Value: " + d);
 }
}
class compilehang {
public static void main(String[] args) {
  double d = 2.2250738585072012e-308;
  System.out.println("Value: " + d);
 }
}

Ráadásként a tizedesjel odéppakolásával és nullák beillesztésével további számok konstruálhatók, melyek mindegyike végtelen ciklusba kergeti az interpretert/fordítót.

Címkék: java bug dos

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

keeroy · http://music.blog.hu 2011.02.01. 19:18:40

%s/odéppakolásával/odébbpakolásával/g

keeroy · http://music.blog.hu 2011.02.01. 19:20:13

s/odéppakolásával/odébbpakolásával

keeroy · http://music.blog.hu 2011.02.01. 19:20:53

sry a dupláért, először nem mutatta hogy megjelent volna a komment. az egyik törölhető, vagy akár mindkettő.

maaaargit · http://katasztrofail.blog.hu/ 2011.02.01. 20:14:54

Bezzeg a ruby!

ruby-1.8.7-p330 :001 > n =2.2250738585072011e-308
=> 2.2250738585072e-308
ruby-1.8.7-p330 :002 > n
=> 2.2250738585072e-308
ruby-1.8.7-p330 :003 > n/2
=> 1.1125369292536e-308

EQ · http://rycon.hu 2011.02.01. 21:43:59

ezután találtunk egy konverziós hibát is a php-ban, bár talán az az 5.2.6-ban volt vagy miben, nem emlékszem... Elég nagy bigint-re ha hozzáadtál egy nullát megváltozott az értéke, de csak az utsó 2számjegy. volt hogy 10jegyű számhoz hozzáadtuk a nullát, előtte 35re végződött, utánna 40re. Ja és éljen a debian friss csomagkészlete :)

nyos 2011.02.02. 04:09:06

@ochronus: ez 64 vagy 32 bitre forditott ruby?
Mert a PHP-bol is csak a 32-eset erintette.

Javaval mi a helyzet? Ott mindegyik erintett?

nyos 2011.02.02. 04:10:30

@ochronus: ez 64 vagy 32 bitre forditott ruby?
Mert a PHP-bol is csak a 32-eset erintette.

Javaval mi a helyzet? Ott mindegyik erintett?

(elobb valami blog.hu bug volt, bocs, ha dupla)

whocares11 2011.02.02. 06:36:18

Java... (kac-kac). A .NET-nek meg sem kottyan holmi 2.2250738585072012e-308 :D

axt · http://axtaxt.wordpress.com/ 2011.02.02. 07:40:32

A 64 és a 32 bites java is érintett ... csak az 1.6-os szériával próbáltam (SunJDK, OpenJDK, JRockit).

deejayy · http://deejayy.hu/ 2011.02.02. 07:57:15

Látta valaki a Pi című filmet? :)

loolek · http://loolek.tumblr.com 2011.02.02. 09:11:35

Ha, a double simán csak 2.2:

D:\>javac -verbose compilehang.java
[parsing started compilehang.java] A
[parsing completed 15ms]
[search path for source files: .]
[search path for class files: c:\jdk1.6.0_23\jre\lib\resources.jar,c:\jdk1.6.0_23\jre\lib\rt.jar,c:\jdk1.6.0_23\jre\lib\sunrsasign.jar,c:\jdk1.6.0_23\j
re\lib\jsse.jar,c:\jdk1.6.0_23\jre\lib\jce.jar,c:\jdk1.6.0_23\jre\lib\charsets.jar,c:\jdk1.6.0_23\jre\lib\modules\jdk.boot.jar,c:\jdk1.6.0_23\jre\class
es,c:\jdk1.6.0_23\jre\lib\ext\dnsns.jar,c:\jdk1.6.0_23\jre\lib\ext\localedata.jar,c:\jdk1.6.0_23\jre\lib\ext\sunjce_provider.jar,c:\jdk1.6.0_23\jre\lib
\ext\sunmscapi.jar,c:\jdk1.6.0_23\jre\lib\ext\sunpkcs11.jar,.]
[loading java\lang\Object.class(java\lang:Object.class)]
[loading java\lang\String.class(java\lang:String.class)]
[checking compilehang]
[loading java\lang\System.class(java\lang:System.class)]
[loading java\io\PrintStream.class(java\io:PrintStream.class)]
[loading java\io\FilterOutputStream.class(java\io:FilterOutputStream.class)]
[loading java\io\OutputStream.class(java\io:OutputStream.class)]
[loading java\lang\StringBuilder.class(java\lang:StringBuilder.class)]
[loading java\lang\AbstractStringBuilder.class(java\lang:AbstractStringBuilder.class)]
[loading java\lang\CharSequence.class(java\lang:CharSequence.class)]
[loading java\io\Serializable.class(java\io:Serializable.class)]
[loading java\lang\Comparable.class(java\lang:Comparable.class)]
[loading java\lang\StringBuffer.class(java\lang:StringBuffer.class)]
[wrote compilehang.class]
[total 156ms]

Viszont, ha a megadott érték, akkor egyből kifagy a parser:

D:\>javac -verbose compilehang.java
[parsing started compilehang.java]

Tyra3l 2011.02.02. 11:02:54

ez komoly, hogy az x87 szo sehol sem szerepel, se a blogpostban, sem a hozzaszolasok kozott?
buherablog-tol tobbet vartam.

Tyrael

Tyra3l 2011.02.02. 11:13:40

www.network-theory.co.uk/docs/gccintro/gccintro_70.html
gcc.gnu.org/bugzilla/show_bug.cgi?id=323

anno a python is belefutott
bugs.python.org/issue2937
nemreg a php, most a java (clojure, scala, etc.)
valoszinuleg ha jol korulneznenk, akkor vagy mas projectek is szivtak vele (2000-es az eredeti gcc-s hibajegy), vagy meg mindig tartalmazzak a hibat.

remelhetoleg a 64bit terjedesevel vegleg elfelejtkezhetunk errol a problemarol.

Tyrael

buherator · http://buhera.blog.hu 2011.02.02. 11:23:06

@Tyra3l: Nem volt időm komolyabban utánamenni a problémának, de ha írsz egy részletesebb elemzést a hibáról, azt nagyon szívesen publikálom!

Egyébként axtaxt kommentje szerint 64 bites Java-n is tapasztalható a jelenség.

Tyra3l 2011.02.02. 12:04:33

@buherator itt jol ossze van foglalva a problema eredete: blog.andreas.org/display?id=9
illetve a javas eset kapcsan a legerdekesebb commentek szerintem itt szulettek az altalad linkelt poston kivul:
hackerne.ws/item?id=2164863
pl. JRuby is erintett, ha hinni lehet az egyik commentelonek (ami logikus lenne, hiszen mint irtam, maga a JVM szenved a problematol)

Tyrael

loolek · http://loolek.tumblr.com 2011.02.02. 17:26:01

EXPLANATION
The x87 FPU was originally designed in (or before) 1980. I think that's why it
is quite simple: it has only one unit for all FP data types. Of course, the
precision must be of the widest type, which is the 80-bit long double.
Consider you have a program, where all the FP variables are of the type double.
You perform some FP operations and one of them is e.g. 1e-300/1e300, which
results in 1e-600. Despite this value cannot be held by a "double", it is
stored in an 80-bit FPU register as the result. Consider you use the variable
"x" to hold that result. If the program has been compiled with optimization,
the value need not be stored in RAM. So, say, it is still in the register.
Consider you need x to be nonzero, so you perform the test x != 0. Since 1e-600
is not zero, the test yields true. While you perform some other computations,
the value is moved to RAM and converted to 0 because x is of type "double". Now
you want to use your certainly nonzero x... Hard luck :-(
Note that if the result doesn't have its corresponding variable and you perform
the test directly on an expression, the problem can come to light even without
optimization.
It could seem that performing all FP operations in extended precision can bring
benefits only. But it introduces a serious pitfall: moving a value may change
the value!!!

more: hal.archives-ouvertes.fr/hal-00128124