Zamanın Tükenmesi – Y2K38 ile nasıl başa çıkılır?

19 Ocak Pazartesi günü şunlardan birini yaşadınız mı? Kart ödemelerinin işlenmesinde aksaklıklar, güvenlik sistemlerinden gelen yanlış alarmlar, tıbbi ekipmanların hatalı çalışması, otomatik aydınlatma, ısıtma ve su tedarik sistemlerinde arızalar veya bunlara benzer başka aksaklıklar… Bazı endüstriyel ve IoT sistemleri de dahil olmak üzere milyonlarca BT sisteminin 19 Ocak’ta öngörülemeyen davranışlar sergilemesi bekleniyordu. Sizin başınıza bu tür bir aksaklık gelmediği için sevinmeyin zira bahsedilen bu olaylar 19 Ocak 2026’da değil 19 Ocak 2038’de gerçekleşecek. Ancak bu; rahatlamak için bir neden değil, çünkü hazırlık için kalan süre şimdiden yetersiz hale gelmiş olabilir. Bu sorunların nedeni, tarih ve saati depolayan tam sayıların kapasitesinin aşılması olacaktır. Hatanın temel nedeni basit ve açık olsa da, bunu düzeltmek için hükümetlerden uluslararası kuruluşlara, organizasyonlardan özel kişilere kadar her düzeyde kapsamlı ve sistematik çabalar gerekecektir.

Unix çağının yazılı olmayan standardı

Unix epoch, Unix işletim sistemleri tarafından benimsenen ve tüm BT endüstrisinde popüler hale gelen zaman ölçüm sistemidir. 1 Ocak 1970 tarihinde UTC saatiyle 00:00:00’dan itibaren saniyeleri sayar ve bu tarih sıfır noktası olarak kabul edilir. Zamanın herhangi bir anı, o tarihten itibaren geçen saniye sayısı olarak temsil edilir. 1970’den önceki tarihler için negatif değerler kullanılır. Bu yaklaşım, basitliği nedeniyle Unix geliştiricileri tarafından tercih edildi. Yıl, ay, gün ve saati ayrı ayrı depolamak yerine tek bir sayı yeterli oluyordu. Bu, sıralama veya tarihler arasındaki aralığı hesaplama gibi işlemleri basitleştirir. Günümüzde Unix epoch, Unix sistemlerinin çok ötesinde; veri tabanlarında, programlama dillerinde, ağ iletişim kurallarında ve iOS ve Android işletim sistemlerini kullanan akıllı telefonlarda kullanılmaktadır.

Y2K38 saatli bomba

Unix geliştirildiğinde, zamanın 32 bitlik işaretli tam sayı olarak depolanmasına karar verildi. Bu, yaklaşık olarak 1901 ile 2038 arasındaki bir tarih aralığını temsil etmeyi mümkün kıldı. Sorun şu ki, 19 Ocak 2038 tarihinde, 03:14:07 UTC’de, bu sayı maksimum değerine (2.147.483.647 saniye) ulaşacak ve taşarak negatif hale gelecek ve bilgisayarların Ocak 2038’den 13 Aralık 1901’e “ışınlanmasına” neden olacaktır. Ancak bazı durumlarda, daha kısa süreli bir “zaman yolculuğu” gerçekleşebilir: Sıfır noktasına, yani 1970 yılına.

“2038 sorunu”, ‘Epochalypse’ veya “Y2K38” olarak bilinen bu olay, POS terminalleri, yerleşik sistemler ve yönlendiricilerden otomobillere ve endüstriyel ekipmanlara kadar, hala 32 bit zaman gösterimi kullanan sistemlerde arızalara yol açabilir. Modern sistemler, zamanı depolamak için 64 bit kullanarak bu sorunu çözümlemektedir. Bu, tarih aralığını yüz milyarlarca yıl ileriye uzatır. Ancak, 32 bit tarih formatına sahip milyonlarca cihaz hala kullanımda olup, “Y günü” gelmeden önce güncellenmesi veya değiştirilmesi gerekecektir.

Bu bağlamda, 32 ve 64 bit özellikle tarih depolama formatını ifade eder. Bir işletim sistemi veya işlemcinin 32 bit veya 64 bit olması, otomatik olarak tarihi “yerel” bit biçiminde depoladığı anlamına gelmez. Ayrıca, birçok uygulama tarihleri tamamen farklı şekillerde depolar ve bit sayısından bağımsız olarak Y2K38 sorunundan etkilenmeyebilir.

1970’den önceki tarihleri işlemek gerekmediğinde, tarih işaretsiz 32 bitlik bir tam sayı olarak saklanır. Bu tür sayılar 1970 ile 2106 arasındaki tarihleri temsil edebilir, bu nedenle sorun daha uzak bir gelecekte ortaya çıkacaktır.

2000 yılı sorunuyla farkları

Yirminci yüzyılın sonlarında ortaya çıkan meşhur 2000 yılı sorunu (Y2K), yılı iki basamaklı olarak depolayan sistemlerin yeni tarihi 1900 yılı ile karıştırabilmesi açısından benzerdi. Hem uzmanlar hem de medya dijital bir kıyamet korkusu yaşadı, ancak sonuçta küresel çapta felaketlere yol açmayan çok sayıda münferit olay meydana geldi.

Y2K38 ile Y2K arasındaki temel fark, hayatımızdaki dijitalleşmenin ölçeğidir. Güncelleme gerektiren sistemlerin sayısı, 20. yüzyıldaki bilgisayarların sayısından çok daha fazladır ve bilgisayarlar tarafından yönetilen günlük görev ve işlemlerin sayısı hesaplanamaz boyuttadır. Bu arada, Y2K38 sorunu, basit yazılım güncellemeleriyle normal bilgisayarlarda ve işletim sistemlerinde zaten çözülmüş durumda ya da yakında çözülecek. Ancak klimaları, asansörleri, pompaları, kapı kilitlerini ve fabrika montaj hatlarını yöneten mikrobilgisayarlar, önümüzdeki on yıl boyunca eski, Y2K38’e karşı savunmasız yazılım sürümleriyle gayet iyi çalışmaya devam edebilir.

Epochalypse ve potansiyel sorunları

Tarihin 1901 veya 1970’e geçmesi, farklı sistemleri farklı şekillerde etkileyecektir. Bazı durumlarda, örneğin her gün saat 19:00’da açılmak üzere programlanmış bir aydınlatma sistemi gibi, bu durum tam olarak fark edilmeyebilir. Tam ve doğru zaman damgalarına dayanan diğer sistemlerde, ciddi bir arıza meydana gelebilir. Örneğin, 2000 yılında ödeme terminalleri ve toplu taşıma turnikeleri çalışmayı durdurmuştu. Komik durumlar da mümkündür, örneğin 1901 tarihli bir doğum belgesi düzenlenmesi gibi. Çok daha kötü olanı ise, ısıtma sisteminin tamamen kapanması veya hastanede kemik iliği analiz sisteminin arızalanması gibi kritik sistemlerin arızalanmasıdır.

Kriptografi, Epochalypse’de özel bir yere sahiptir. 2038 ile 2000 arasındaki bir diğer önemli fark, tüm iletişimi korumak için şifreleme ve dijital imzaların yaygın olarak kullanılmasıdır. Cihazın tarihi yanlışsa, güvenlik sertifikaları genellikle doğrulamada başarısız olur. Bu, savunmasız bir cihazın çoğu iletişimden kesileceği anlamına gelir; temel iş uygulamalarında tarihi yanlış işleyen herhangi bir kod olmasa bile.

Ne yazık ki, tüm sonuçların tam spektrumu, tüm sistemlerin kontrollü testleri ve olası arıza zincirlerinin ayrı ayrı analizleri ile belirlenebilir.

Y2K38’in kötüye kullanımı

BT ve Bilgi Güvenliği ekipleri, Y2K38’i basit bir yazılım hatası olarak değil, hizmet reddi dahil olmak üzere çeşitli arızalara yol açabilecek bir güvenlik açığı olarak ele almalıdır. Bazı durumlarda, kötü niyetli kişiler tarafından istismar edilebilir. Bunu yapmak için, hedef sistemdeki zamanı manipüle etme yeteneğine sahip olmaları gerekir. Bu, en az iki senaryoda mümkündür:

• Saldırıya uğrayan sisteme sahte bir zaman sunucusu besleyerek NTP iletişim kuralı verilerine müdahale etmek
• Sistem uydu zamanına bağlıysa GPS sinyalini taklit etmek

Bu hatanın istismarı, güvenlik açıklarının geleneksel olarak yavaş bir şekilde düzeltildiği ve bir arızanın sonuçlarının çok daha ciddi olabileceği OT ve IoT sistemlerinde en olasıdır.

Zaman sayımıyla ilgili kolayca istismar edilebilen bir güvenlik açığı örneği, Dover ProGauge MagLink LX4 otomatik yakıt deposu gösterge konsollarındaki CVE-2025-55068 (CVSSv3 8.2, CVSSv4 taban 8.8) güvenlik açığıdır. Zaman manipülasyonu, benzin istasyonunda hizmet reddine neden olabilir ve cihazın web yönetim paneline erişimi engelleyebilir. Bu kusur, CISA tarafından ayrı bir uyarı yayınlanmasına neden olmuştur.

Y2K38 etkilerinin azaltılmasının mevcut durumu

Y2K38 sorununu çözmek için gerekli temeller, başlıca işletim sistemlerinde başarıyla atılmıştır. Linux çekirdeği, 2020 yılında 5.6 sürümünden itibaren 32 bit mimarilerde bile 64 bit zaman desteği ekledi ve 64 bit Linux bu sorundan her zaman korunmuştur. BSD ailesi, macOS ve iOS, tüm modern cihazlarda 64 bit zaman kullanır. 21. yüzyılda piyasaya sürülen tüm Windows sürümleri Y2K38’den etkilenmez.

Veri depolama ve uygulama düzeyindeki durum çok daha karmaşıktır. ZFS, F2FS, NTFS ve ReFS gibi modern dosya sistemleri 64 bit zaman damgaları ile tasarlanırken, ext2 ve ext3 gibi eski sistemler hala savunmasızdır. Ext4 ve XFS, belirli bayrakların etkinleştirilmesini gerektirir (ext4 için genişletilmiş inode ve XFS için bigtime) ve mevcut dosya sistemlerinin çevrimdışı dönüştürülmesi gerekebilir. NFSv2 ve NFSv3 iletişim kurallarında, eski zaman depolama biçimi devam etmektedir. Veri tabanlarında da benzer bir durum söz konusudur: MySQL’deki TIMESTAMP türü temel olarak 2038 yılıyla sınırlıdır ve DATETIME’a geçiş gerektirirken, PostgreSQL’deki standart zaman damgası türleri güvenlidir. C dilinde yazılmış uygulamalar için, 32 bit mimarilerde 64 bit zamanı kullanmak üzere yollar oluşturulmuştur, ancak tüm projelerin yeniden derlenmesi gerekmektedir. Java, Python ve Go gibi diller genellikle taşmayı önleyen türler kullanır, ancak derlenmiş projelerin güvenliği, C ile yazılmış savunmasız kütüphanelerle etkileşime girip girmediklerine bağlıdır.

Çok sayıda 32 bit sistem, yerleşik cihaz ve uygulama; yeniden oluşturulup test edilene ve tüm kullanıcıları tarafından güncellemeler yüklenene kadar, savunmasız kalmaya devam edecektir.

Çeşitli kuruluşlar ve meraklılar bu konudaki bilgileri sistematik hale getirmeye çalışıyorlar, ancak çabaları bölünmüş durumda. Sonuç olarak, “ortak Y2K38 güvenlik açığı veri tabanı” diye bir şey yok.  (1, 2, 3, 4, 5).

Y2K38’i düzeltme yaklaşımları

Zayıf noktaları önceliklendirme ve düzeltme için oluşturulan metodolojiler, 2038 sorununa doğrudan uygulanabilir. En büyük zorluk, günümüzde hiçbir aracın savunmasız yazılım ve donanımların eksiksiz bir listesini oluşturamaması olacaktır. Bu nedenle, kurumsal BT varlıklarının envanterini güncellemek, envanterin aygıt yazılımı ve yüklü yazılımlarla ilgili ayrıntılı bilgilerle zenginleştirilmesini sağlamak ve ardından güvenlik açığı sorununu sistematik olarak araştırmak çok önemlidir.

Liste, iş sistemlerinin kritik önemi ve her sistemin dayandığı teknoloji yığınının verilerine göre önceliklendirilebilir. Sonraki adımlar şunlardır: Satıcının destek portalını incelemek, donanım ve yazılım üreticilerinden Y2K38 durumları hakkında doğrudan bilgi almak ve son çare olarak test yoluyla doğrulama yapmak.

Kurumsal sistemleri test ederken, özel önlemler almak çok önemlidir:

• Üretim sistemlerini asla test etmeyin.
• Testten hemen önce bir veri yedeği oluşturun.
• Test edilen sistemi iletişimden izole edin, böylece kuruluş içindeki diğer sistemleri karıştırmasın.
• Tarih değişikliği NTP veya GPS kullanıyorsa, 2038 test sinyallerinin diğer sistemlere ulaşmadığından emin olun.
• Testten sonra, sistemleri doğru saate geri ayarlayın ve gözlemlenen tüm sistem davranışlarını ayrıntılı olarak belgelendirin.

Bir sistemin Y2K38’e karşı savunmasız olduğu tespit edilirse, satıcıdan bir düzeltme zaman çizelgesi talep edilmelidir. Düzeltme mümkün değilse, geçiş planı yapın; neyse ki, kalan zamanımız oldukça karmaşık ve pahalı sistemleri bile güncellemeye yetiyor.

Y2K38 sorununu ele alırken en önemli şey, bunu çözümünün beş ila sekiz yıl daha, kolayca ertelenebilecek uzak bir gelecek sorunu olarak görmemektir. Bu kusuru tamamen ortadan kaldırmak için zaten yeterli zamanımız olmadığı çok muhtemeldir. Ancak, bir kuruluş ve onun teknoloji filosu içinde, sorunu çözmek için dikkatli bir planlama ve sistematik bir yaklaşım, bunu zamanında gerçekleştirebilmeyi sağlayacaktır.